Bug#850224: wiki.debian.org: DNSSEC page most test commands and links not working anymore

[Ralf]

Package: wiki.debian.org
Severity: important

Hi,

Most of the DNSSEC Wiki page "Test DNSSEC" section doesn't work anymore.

* The first Command line test "dig org. SOA +dnssec" still works though it 
would be nice to add +multiline to the and of the command for better 
readability of the output.

* The second command "dig +short test.dnssec-or-not.net TXT | tail -1" does not 
work anymore. When you visit the URL you get this message: The "dnssec-or-not" 
web site is going through a redesign. Previously the test was implemented 
entirely using the DNS protocol. Unfortunately, a DNS server cannot be 
absolutely sure that a DNS client is fully protected by DNSSEC. This led to 
false positives. The test is being redesigned to increase its accuracy.

* The third command "dig +noall +comments dnssec-failed.org" seems okay.

In the "Web-based" section:

* The first URL shows an error ("The separate test for DNSSEC-validation 
available here has now been integrated in this test: https://internet.nl;) so 
it is better changed to that URL.

* The second URL also shows and error ("The dnssec-or-not web site is going 
through a redesign. Previously the test was implemented entirely using the DNS 
protocol. Unfortunately, a DNS server cannot be absolutely sure that a DNS 
client is fully protected by DNSSEC. This led to false positives. The test is 
being redesigned to increase its accuracy.") so it is better to remove it.


Greetings,
Ralf Vroomen.

Bug#845167: lemonldap-ng: FTBFS randomly (failing tests)

[Xavier Guimard]

Hi,

looking at
http://matrix.cpantesters.org/?dist=Lemonldap-NG-Handler+1.9.7
the bug seems to be specific to Debian. I've disabled the heavy handler
tests for now in 1.9.7-2.

Note that autopkgtest fails since FastCGI server depends on Nginx which
can not be installed in autopkgtest environment.

Regards,
Xavier



signature.asc
Description: OpenPGP digital signature

Bug#845075: kernel-image-4.8.0-1-armmp-di: Lamobo R1 cannot access network

[Vagrant Cascadian]

On 2017-01-04, Ben Hutchings wrote:
>> I want to install Debian Stretch on my Lamobo R1 using the network
>> installer.
>> 
>> It is unable to connect to the DHCP server.
>> 
>> Please, add the b53 module to the kernel.
>> 
>> CONFIG_B53=y
>> CONFIG_B53_SPI_DRIVER=y
>
> I think we already enabled the necessary options:
>
>   * [armhf] dsa: Enable drivers for Lamobo R1 (aka BPi-R1): B53,
> B53_MDIO_DRIVER as modules (Closes: #836231, thanks to Vagrant Cascadian)
>
> From the device tree, it seems pretty clear that we do want
> B53_MDIO_DRIVER and not B53_SPI_DRIVER.  Are you sure the installer
> version you used had a verison 4.8 kernel, not 4.7?

I had very mixed luck with the switch driver with 4.7.x and 4.8.x, but
ethernet generally worked ok. With 4.9.x, I was able to get all ports
working well.

Were you plugging into the WAN port, or one of the switch ports?

Is the b53 module listed in nic-modules udeb? I don't see mention of it
at a quick glance, or is it pulled in with some globbing?


live well,
  vagrant

p.s. I've haven't been tracking the udebs as much lately, tired of
playing whack-a-mole with the exact right modules in the exact right
udeb... instead I've been manually appending all the drivers into the
initrd as an additional cpio archive...


signature.asc
Description: PGP signature

Bug#806720: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

[TFAUCK]

Agree on frediz taking ownership of that bugs
Thanks

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

Bug#850223: dogecoin: OpenSSL 1.1 patch introduces "memory leak on error"

[Niels Thykier]

Package: dogecoin
Version: 1.10.0-4
Severity: important
Tags: security

Hi,

The OpenSSL 1.1 patch introduces a memory leak on error AFAICT.

Consider this following patch hunk with inline comments.

+--- dogecoin-1.10.0.orig/src/qt/paymentrequestplus.cpp
 dogecoin-1.10.0/src/qt/paymentrequestplus.cpp
+@@ -161,14 +161,15 @@
+ std::string data_to_verify; // Everything but the 
signature
+ rcopy.SerializeToString(_to_verify);
+ 
+-EVP_MD_CTX ctx;
++EVP_MD_CTX *ctx = EVP_MD_CTX_new();
  ^^^

Allocation

+ EVP_PKEY *pubkey = X509_get_pubkey(signing_cert);
+-EVP_MD_CTX_init();
+-if (!EVP_VerifyInit_ex(, digestAlgorithm, NULL) ||
+-!EVP_VerifyUpdate(, data_to_verify.data(), 
data_to_verify.size()) ||
+-!EVP_VerifyFinal(, (const unsigned 
char*)paymentRequest.signature().data(), (unsigned 
int)paymentRequest.signature().size(), pubkey)) {
++EVP_MD_CTX_init(ctx);
++if (!EVP_VerifyInit_ex(ctx, digestAlgorithm, NULL) ||
++!EVP_VerifyUpdate(ctx, data_to_verify.data(), 
data_to_verify.size()) ||
++!EVP_VerifyFinal(ctx, (const unsigned 
char*)paymentRequest.signature().data(), (unsigned 
int)paymentRequest.signature().size(), pubkey)) {
+ throw SSLVerifyError("Bad signature, invalid payment request.");
  

No EVP_MD_CTX_free(ctx); before throw in this path

+ }
++  EVP_MD_CTX_free(ctx);
+ 
+ // OpenSSL API for getting human printable strings from certs is 
baroque.
+ int textlen = X509_NAME_get_text_by_NID(certname, NID_commonName, 
NULL, 0);

Bug#847538: Followup

[Josh Triplett]

Following up on this.  Any chance of a version of synaptic with this
patch included, before the freeze?

- Josh Triplett

Bug#814030: Security flaw fixed in version 6.2.0

[Salvatore Bonaccorso]

Hi David,

On Sun, Mar 27, 2016 at 01:33:01PM +0200, Moritz Mühlenhoff wrote:
> On Sun, Feb 07, 2016 at 02:28:04PM -0400, David Prévot wrote:
> > Package: php-tcpdf
> > Version: 6.0.093+dfsg-1
> > Severity: serious
> > Tags: security upstream
> > 
> > According to their changelog [1], upstream fixed a security issue over a
> > year ago:
> > 
> > 6.2.0 (2014-12-10)
> > - Bug #1005 "Security Report, LFI posting internal files externally 
> > abusing default parameter" was fixed.
> > 
> > 1: https://sourceforge.net/p/tcpdf/code/ci/master/tree/CHANGELOG.TXT
> > 
> > The upstream bug report [2] is not public, so I don’t have much
> > information about the issue, the fix, nor it’s actual severity.
> > 
> > 2: https://sourceforge.net/p/tcpdf/bugs/1005/
> 
> Can you contact upstream for information on this security bug? I have
> no idea what that could possibly mean.

Did you got any information on that from upstream? The bug is stil
closed, so does not really help.

Regards,
Salvatore

Bug#734688: Call for testers: logrotate 3.11.0-0.1~exp1

[Christoph Biedl]

Matthias Klose wrote...

> fyi, I NMUed logrotate yesterday to fix #849743, currently in delayed.  Please
> add this fix to your upload.

Thanks for the heads-up, included in ~exp2 I had to do for other
reasons as well.

Christoph


signature.asc
Description: Digital signature

Bug#850222: ITP: node-plur -- Pluralize a word

[Abhishek Lolage]

Package: wnpp
Severity: wishlist
Owner: Abhishek Lolage 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-plur
  Version : 2.1.2
  Upstream Author : Sindre Sorhus  (sindresorhus.com)

* URL : https://github.com/sindresorhus/plur
* License : Expat
  Programming Lang: JavaScript
  Description : Pluralize a word

Bug#849918: RFS: tinymux/2.10.1.13-1

[Tobias Frost]

Control: tags -1 moreinfo

Am Mittwoch, den 04.01.2017, 20:15 -0700 schrieb Stephen Dennis:
> Thanks for the starting point. I had worked out the d/watch file
> enough
> that it works locally (mentors.debian.net still complains), but I
> like your
> wildcards better, so I'm using that one (mentors.debian.net still
> complains). 

It could be that mentors has an older uscan which does not yet
understand version=4.
Please note that my version is not perfect, but I'd also would have to
ask to make it so (e.g on #debian-mentors): As your layout on your
server is complicated, the current file cannot properly dectect future
version, like a 2.12... (E.g the directory depth differs and also once
uscan detected the 2.12 directory it won't look into the 2.10 anymore,
because I guess you want the alpha not listed as new version.)
Maybe you can bring your example on #debian-mentors if there is an 
solution. (Not needed for this sponsoring)
(You can also utilize the fact that you're upstream and easethings by
placing a link on your homepage which can more easily consumed by
uscan.

BTW, you're using the tar.gz .. Can you use the tar.bz2 for the
packaging as it compresses better? This is also the one that is picked
up by uscan... (Just use uscan --force-download to get a copy and then
delete the other one)
 
> The simple short d/rules is very much appreciated. I only just
> begin to discover the override_* stuff before you sent it. You saved
> me two
> days there. That and writing d/install and d/clean exposed some
> embarrassing stray symbolic links. I actually prefer enumerating the
> exact
> placement of all the files. So, what remains:

Thanks for looking into it.
remarks:
- d/clean: You can use wildcards, eg. it is less fragile if your clean
games/bin/* instead of the individual files.
- you do not need to d/clean condig.(log|status)

About the install:
- there are a few files with *.conf that are going to /usr/share/...
Are they conf-files that should actually go to /etc/ as a kind of
system-wide configuration?


>  - I think the fortify complaint about slave and stubslave is
> probably
> because they are so minimal. I don't think they use any libc
> functions actually.

OK, could be a wrong positive (didn't check)

>  - There's no obvious override for the duplicate changelog warning.

The problem is that dh_installchangelogs will pick it up, but you've
got it also specified in d/docs.

You shouldn't install the doc INSTALL, as this is not relevant for
Debian binary packages -- it talks mostly about how to compile etc.
(README.Debian takes it job appearantly already)

>  - Revisit d/changelog to make sure the package changes are fully
> captured.

Yes, they are super-verbose now... (even a bit too much, but how should
you know ;-)  Example:

   * As the package is being adopted by Stephen Dennis 
 ,changed the Maintainer in debian/control 
 from Ervin Hearn III  to Stephen Dennis 
 .

While this explains the why very well (and is too extensive on the what
(this is will be in the diff) Convention is just to write: 
   * New maintainer. (Closes: #YourITABugNumber) 

The others are also a bit extensive on the "what" area, but I suggest
that this is declared "OK" -- extensive is better than terse. 


>  - It would be nice to get make -j2 working. They did work once upon
> a
> time. Might be better to fix that upstream.

Yes, I do not consider this as a blocking point for now.

>  - Test. The prettiest package in the world doesn't necessarily
> install
> anything that works.

Of course.

One thing I noted: NOTES mentions there is a default password. (I guess
it it a kind of admin password) This is a bad idea, securitywise and 
should be changed. 

> On Wed, Jan 4, 2017 at 4:32 PM, Tobias Frost  wrote:
> 
> > Am Donnerstag, den 05.01.2017, 00:24 +0100 schrieb Tobias Frost:
> > > 
> > > I wrote you a rule file as starting point. Attached. It is
> > > thought to
> > > get you started.
> > > (Some parts are missing, like the hardening; also stuff and you
> > > need
> > > to
> > > do outside of the rules, like to create the file d/clean with all
> > > files
> > > listed and d/install to to put the files actually in place
> > > 
> > 
> > PS: I needed to add --no-parallel because parallel build is broken
> > here. This is also bug in your Makefile...
> > 
> > To trigger
> > #debuild -j1
> > (works)
> > 
> > #debuild -j4
> > (...)
> > g++ -g -O2 -fdebug-prefix-
> > map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=.
> > -fstack-
> > protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> > frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> > DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o stubslave stubslave.o
> > -L.
> > -lm -lcrypt   -lmux
> > /usr/bin/ld: cannot find -lmux
> > collect2: error: ld returned 1 exit status
> > Makefile:189: recipe for target 'stubslave' failed
> > make[1]: *** 

Bug#850221: linux-image-4.8.0-2-amd64: Screen switched off after resume from hibernate

[solitone]

Package: src:linux
Version: 4.8.11-1
Severity: important

When the screen is already switched off and then the system 
hibernates, it won't resume correctly later on. Specifically, the 
monitor will be switched off again at the end of the resume 
process.

E.g. I give the following command in order to switch off the monitor:

$ sleep 1 && xset dpms force off

then I close the lid so that my system hibernates. Then I resume 
the system. The monitors turns on, as I see the boot loader screen 
and some boot messages. But then, when the resume is complete, the
screen is switched off again, and there is no way to turn it on.
The only solution is press the power button to turn off the entire
computer.

I get the same issue even when, instead of using the xset command,
I wait several minutes so that the screen is switched off 
automatically by KDE's power management, and then I hibernate 
the system.

By contrast, I have no issue if I hibernate when the screen is still on.
The resume works perfectly well. Besides, suspend (to RAM) has no issue
either, both when the screen is on and when it is off. 


-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=7f537d3b-e578-4cd3-8583-f3a2281f7d01 ro quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[3.469211] iTCO_vendor_support: vendor-support=0
[3.471624] scsi 1:0:0:0: Direct-Access APPLESD Card Reader   3.00 
PQ: 0 ANSI: 6
[3.471634] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[3.471668] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by 
hardware/BIOS
[3.476176] applesmc: key=670 fan=1 temp=35 index=34 acc=0 lux=2 kbd=1
[3.479708] sd 1:0:0:0: Attached scsi generic sg1 type 0
[3.481135] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[3.592678] brcmfmac :03:00.0: firmware: direct-loading firmware 
brcm/brcmfmac43602-pcie.bin
[3.592689] brcmfmac :03:00.0: firmware: failed to load 
brcm/brcmfmac43602-pcie.txt (-2)
[3.592690] brcmfmac :03:00.0: Direct firmware load for 
brcm/brcmfmac43602-pcie.txt failed with error -2
[4.103854] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Nov 10 
2015 06:38:10 version 7.35.177.61 (r598657) FWID 01-ea662a8c
[4.145437] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 
0x30)
[4.150980] brcmfmac :03:00.0 wlp3s0: renamed from wlan0
[4.696723] Console: switching to colour frame buffer device 320x100
[4.723776] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[4.745332] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input13
[4.745393] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input14
[4.745448] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input15
[4.937031] random: crng init done
[5.054201] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[5.054203] Bluetooth: BNEP filters: protocol multicast
[5.054206] Bluetooth: BNEP socket layer initialized
[5.278960] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[5.321774] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[5.860452] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[5.926967] ip6_tables: (C) 2000-2006 Netfilter Core Team
[5.942217] Ebtables v2.0 registered
[6.006575] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[6.006580] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlp3s0 
type 10 failed: err=-16
[6.010063] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[9.129416] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   11.724329] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[   11.794317] brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table 
err:-23
[   12.004260] systemd[1]: apt-daily.timer: Adding 1h 10min 16.850607s random 
time.
[   12.188006] systemd[1]: apt-daily.timer: Adding 2h 54min 17.772584s random 
time.
[   21.962670] Bluetooth: RFCOMM TTY layer initialized
[   21.962681] Bluetooth: RFCOMM socket layer initialized
[   21.962688] Bluetooth: RFCOMM ver 1.11
[  820.678018] perf: interrupt took too long (2539 > 2500), lowering 
kernel.perf_event_max_sample_rate to 78750
[  917.699599] perf: interrupt took too long (3293 > 3173), lowering 
kernel.perf_event_max_sample_rate to 60500
[ 1397.653999] perf: interrupt took too long (4165 > 4116), lowering 
kernel.perf_event_max_sample_rate to 48000
[ 1410.032630] FS-Cache: Loaded
[ 1410.040874] FS-Cache: Netfs 'nfs' registered for caching
[ 1410.042187] Key type dns_resolver registered
[ 1410.050844] NFS: Registering the id_resolver key type
[ 1410.050852] Key type id_resolver registered
[ 1410.050853] Key type id_legacy registered
[ 1410.187520] [ cut 

Bug#850160: Incomplete fix (was: Re: Bug#850160 closed by Reiner Herrmann <rei...@reiner-h.de> (Bug#850160: fixed in firejail 0.9.44.2-2))

[Salvatore Bonaccorso]

Hi Reiner,

On Wed, Jan 04, 2017 at 11:21:05PM +, Debian Bug Tracking System wrote:
>* Add upstream fix for CVE-2017-5180 (Closes: #850160).

Thanks. The fix had a followup which does not seem to be applied, cf.
https://github.com/netblue30/firejail/issues/1020#issuecomment-270514760

Regards,
Salvatore

Bug#850220: ITP: node-get-port -- Get an available port

[Nupur Malpani]

Package: wnpp
Severity: wishlist
Owner: Nupur Malpani 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-get-port
  Version : 2.1.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/get-port
* License : Expat
  Programming Lang: JavaScript
  Description : Get an available port

Bug#850214: jessie-pu: package jq/1.4-2.2

[Adam D. Barratt]

On Thu, 2017-01-05 at 01:37 -0500, Harlan Lieberman-Berg wrote:
> "Adam D. Barratt"  writes:
> > On Thu, 2017-01-05 at 07:12 +0100, Salvatore Bonaccorso wrote:
> >> Disclaimer: I'm not a member of release team, so this is not binding
> >> statement :-)
> 
> Good advice is appreciated, no matter the source!
> 
> > What Salvatore said, please. :-)
> 
> Rebuilt with the corrected version.  debdiff attached.

Thanks; please go ahead. (That was implicit in the previous message, but
I realise possibly not obvious.)

Regards,

Adam

Bug#850214: jessie-pu: package jq/1.4-2.2

[Harlan Lieberman-Berg]

"Adam D. Barratt"  writes:
> On Thu, 2017-01-05 at 07:12 +0100, Salvatore Bonaccorso wrote:
>> Disclaimer: I'm not a member of release team, so this is not binding
>> statement :-)

Good advice is appreciated, no matter the source!

> What Salvatore said, please. :-)

Rebuilt with the corrected version.  debdiff attached.

diff -Nru jq-1.4/debian/changelog jq-1.4/debian/changelog
--- jq-1.4/debian/changelog	2014-07-21 02:53:57.0 -0400
+++ jq-1.4/debian/changelog	2017-01-05 00:26:08.0 -0500
@@ -1,3 +1,11 @@
+jq (1.4-2.1+deb8u1) jessie; urgency=high
+
+  * Non-maintainer upload.
+  * Add patch to fix CVE-2015-8863. (Closes: #802231)
+  * Add patch to fix CVE-2016-4074. (Closes: #822456)
+
+ -- Harlan Lieberman-Berg   Thu, 05 Jan 2017 00:26:08 -0500
+
 jq (1.4-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru jq-1.4/debian/patches/heap-buffer-overflow.patch jq-1.4/debian/patches/heap-buffer-overflow.patch
--- jq-1.4/debian/patches/heap-buffer-overflow.patch	1969-12-31 19:00:00.0 -0500
+++ jq-1.4/debian/patches/heap-buffer-overflow.patch	2017-01-05 00:26:08.0 -0500
@@ -0,0 +1,32 @@
+From 8eb1367ca44e772963e704a700ef72ae2e12babd Mon Sep 17 00:00:00 2001
+From: Nicolas Williams 
+Date: Sat, 24 Oct 2015 17:24:57 -0500
+Subject: [PATCH] Heap buffer overflow in tokenadd() (fix #105)
+
+This was an off-by one: the NUL terminator byte was not allocated on
+resize.  This was triggered by JSON-encoded numbers longer than 256
+bytes.
+---
+ src/jv_parse.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/jv_parse.c
 b/jv_parse.c
+@@ -172,7 +172,7 @@
+ 
+ static void tokenadd(struct jv_parser* p, char c) {
+   assert(p->tokenpos <= p->tokenlen);
+-  if (p->tokenpos == p->tokenlen) {
++  if (p->tokenpos >= (p->tokenlen - 1)) {
+ p->tokenlen = p->tokenlen*2 + 256;
+ p->tokenbuf = jv_mem_realloc(p->tokenbuf, p->tokenlen);
+   }
+@@ -271,7 +271,7 @@
+ TRY(value(p, v));
+   } else {
+ // FIXME: better parser
+-p->tokenbuf[p->tokenpos] = 0; // FIXME: invalid
++p->tokenbuf[p->tokenpos] = 0;
+ char* end = 0;
+ double d = jvp_strtod(>dtoa, p->tokenbuf, );
+ if (end == 0 || *end != 0)
diff -Nru jq-1.4/debian/patches/series jq-1.4/debian/patches/series
--- jq-1.4/debian/patches/series	2014-07-21 02:34:21.0 -0400
+++ jq-1.4/debian/patches/series	2017-01-05 00:26:08.0 -0500
@@ -4,3 +4,5 @@
 patch-version-into-build.patch
 disable-shared-lib.patch
 big-endian-fix.patch
+stack-exhaustion.patch
+heap-buffer-overflow.patch
diff -Nru jq-1.4/debian/patches/stack-exhaustion.patch jq-1.4/debian/patches/stack-exhaustion.patch
--- jq-1.4/debian/patches/stack-exhaustion.patch	1969-12-31 19:00:00.0 -0500
+++ jq-1.4/debian/patches/stack-exhaustion.patch	2017-01-05 00:26:08.0 -0500
@@ -0,0 +1,62 @@
+From 2d38a12d686a5156d4e7afb1fed7851805590582 Mon Sep 17 00:00:00 2001
+From: W-Mark Kubacki 
+Date: Fri, 19 Aug 2016 19:50:39 +0200
+Subject: [PATCH] Skip printing at MAX_DEPTH and deeper
+
+This addresses #1136, and mitigates a stack exhaustion when printing
+a very deeply nested term.
+
+Updated by hlieber...@debian.org for security backport to 1.4.
+---
+ src/jv_print.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+--- a/jv_print.c
 b/jv_print.c
+@@ -7,13 +7,17 @@
+ #include "jv_dtoa.h"
+ #include "jv_unicode.h"
+ 
++#ifndef MAX_DEPTH
++#define MAX_DEPTH 256
++#endif
++
+ #define ESC "\033"
+ #define COL(c) (ESC "[" c "m")
+ #define COLRESET (ESC "[0m")
+ 
+ // Colour table. See http://en.wikipedia.org/wiki/ANSI_escape_code#Colors
+ // for how to choose these.
+-static const jv_kind colour_kinds[] = 
++static const jv_kind colour_kinds[] =
+   {JV_KIND_NULL,   JV_KIND_FALSE, JV_KIND_TRUE, JV_KIND_NUMBER,
+JV_KIND_STRING, JV_KIND_ARRAY, JV_KIND_OBJECT};
+ static const char* const colours[] =
+@@ -99,7 +103,7 @@
+ sprintf(buf, "\\u%04x", c);
+   } else {
+ c -= 0x1;
+-sprintf(buf, "\\u%04x\\u%04x", 
++sprintf(buf, "\\u%04x\\u%04x",
+ 0xD800 | ((c & 0xffc00) >> 10),
+ 0xDC00 | (c & 0x003ff));
+   }
+@@ -124,7 +128,9 @@
+   }
+ }
+   }
+-  switch (jv_get_kind(x)) {
++  if (indent > MAX_DEPTH) {
++put_str("", F, S);
++  } else switch (jv_get_kind(x)) {
+   default:
+   case JV_KIND_INVALID:
+ assert(0 && "Invalid value");
+@@ -242,7 +248,7 @@
+   if (colour) put_str(colour, F, S);
+   put_str((flags & JV_PRINT_PRETTY) ? ": " : ":", F, S);
+   if (colour) put_str(COLRESET, F, S);
+-  
++
+   jv_dump_term(C, value, flags, indent + INDENT, F, S);
+   if (colour) put_str(colour, F, S);
+ }

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#850219: nouveaufb: error switching to higher resolution HDMI, 720p

[Ulrich Möhrke]

Package: src:linux
Version: 4.8.11-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 start of the system
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
 switching to another video mode without success (TV does show
HDMI without video mode)
 no more output to the screen
 error in journalctl (last line of the following)
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: VRAM: 64 MiB
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: TMDS table
version 2.0
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB version 4.0
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB outp 00:
02000300 001e
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB outp 01:
01000302 00020030
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB outp 02:
02011332 00020010
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB conn 00:

Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB conn 01:
1131
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: DCB conn 02:
2261
Jan 05 06:12:46 media kernel: [drm] Supports vblank timestamp caching
Rev 2 (21.10.2013).
Jan 05 06:12:46 media kernel: [drm] Driver supports precise vblank
timestamp query.
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: MM: using M2MF
for buffer copies
Jan 05 06:12:46 media kernel: usb 1-3.2: New USB device found,
idVendor=04d9, idProduct=1503
Jan 05 06:12:46 media kernel: usb 1-3.2: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
Jan 05 06:12:46 media kernel: usb 1-3.2: Product: USB Keyboard
Jan 05 06:12:46 media kernel: usb 1-3.2: Manufacturer:
Jan 05 06:12:46 media kernel: input:   USB Keyboard as
/devices/pci:00/:00:04.1/usb1/1-3/1-3.2/1-3.2:1.0/0003:04D9:1503.0002/input/input6
Jan 05 06:12:46 media kernel: hid-generic 0003:04D9:1503.0002:
input,hidraw1: USB HID v1.10 Keyboard [  USB Keyboard] on
usb-:00:04.1-3.2/input0
Jan 05 06:12:46 media kernel: nouveau :03:00.0: DRM: allocated
1920x1080 fb: 0x5, bo a365f5097800
Jan 05 06:12:46 media kernel: fbcon: nouveaufb (fb0) is primary device
Jan 05 06:12:46 media kernel: nouveau :03:00.0: disp: ERROR 4
[INVALID_VALUE] 84 [] chid 0 mthd 0828 data 99bb


   * What outcome did you expect instead?
 switching to video mode 720p
 it works fine starting with linux-image-3.16.0-4-amd64
 error occurs also with linux-image-4.8.0-1-amd64

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


-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc
version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1
(2016-12-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64
root=UUID=8575e061-200c-4d4c-8241-2e08c262e765 ro quiet

** Not tainted

** Kernel log:
[4.677022] sd 7:0:0:0: [sdb] 625142448 512-byte logical blocks: (320
GB/298 GiB)
[4.680570] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160
GB/149 GiB)
[4.681966] sd 7:0:0:0: [sdb] Write Protect is off
[4.681978] sd 7:0:0:0: [sdb] Mode Sense: 21 00 00 00
[4.683077] sd 6:0:0:0: [sdc] Write Protect is off
[4.683085] sd 6:0:0:0: [sdc] Mode Sense: 28 00 00 00
[4.684363] sd 7:0:0:0: [sdb] No Caching mode page found
[4.684370] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[4.685463] sd 6:0:0:0: [sdc] No Caching mode page found
[4.685471] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[4.691034]  sdb: sdb1
[4.697382] sd 7:0:0:0: [sdb] Attached SCSI disk
[4.725242] usb 1-3.3: New USB device found, idVendor=093a,
idProduct=2510
[4.725247] usb 1-3.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[4.725250] usb 1-3.3: Product: USB Optical Mouse
[4.725253] usb 1-3.3: Manufacturer: PixArt
[4.728875] input: PixArt USB Optical Mouse as
/devices/pci:00/:00:04.1/usb1/1-3/1-3.3/1-3.3:1.0/0003:093A:2510.0004/input/input8
[4.729240] hid-generic 0003:093A:2510.0004: input,hidraw3: USB HID
v1.11 Mouse [PixArt USB Optical Mouse] on usb-:00:04.1-3.3/input0
[4.865849]  sdc: sdc1
[4.872089] sd 6:0:0:0: [sdc] Attached SCSI disk
[5.219718] scsi 8:0:0:0: Direct-Access Generic- Multi-Card
1.00 PQ: 0 ANSI: 0 CCS
[5.854051] sd 8:0:0:0: [sdd] 62333952 512-byte logical blocks: (31.9
GB/29.7 GiB)
[5.856122] floppy0: no floppy controllers found
[5.856139] sd 8:0:0:0: [sdd] Write Protect is off
[5.856146] sd 8:0:0:0: [sdd] Mode Sense: 03 00 00 00
[5.858052] sd 8:0:0:0: [sdd] No Caching mode page found
[5.858057] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[5.870893]  sdd: sdd1 sdd2 < sdd5 >
[5.878094] sd 8:0:0:0: [sdd] Attached SCSI 

Bug#848365: jessie-pu: package coquelicot/0.9.2-4+deb8u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Fri, 2016-12-16 at 18:31 +0100, Jérémy Bobbio wrote:
> I would like to important issues affecting coquelicot in jessie:
> 
> #809351: properly run coquelicot under the 'coquelicot' user and not
> as root. It was always intended that way, that's why the cron is running
> under the coquelicot user already. The issue has been fixed a while ago
> for stretch (in 0.9.4-1, uploaded September 2015). This backports the
> changes from the unstable branch which switched to using
> init-d-script(5).
> 
> #808018: silence deprecation warnings coming from cron. While the
> warnings actually come from ruby-fast-gettext, they make the garbage
> collection cron send an email on every run.

+ sysvinit-utils (>= 2.88dsf-50),

What's that for? sysvinit-utils is Essential:yes.

Hmmm, so the answer appears to be "because that's when init-d-script(5)
was added". That doesn't really seem like a minimal change for fixing
the user that the daemon is running as.

Regards,

Adam

Bug#850217: parcimonie-applet: status icon menu is broken

[Paul Wise]

On Thu, 2017-01-05 at 14:14 +0800, Paul Wise wrote:

> Also, I note that this function has been deprecated in the underlying GTK+ 
> library:
> 
> https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html#gtk-status-icon-position-menu

In addition, the Gtk3::Menu::popup function is also deprecated:

https://developer.gnome.org/gtk3/stable/GtkMenu.html#gtk-menu-popup

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2016-12-16 at 10:17 -0200, Henrique de Moraes Holschuh wrote:
> I would like to update the intel-microcode packages in stable to address
> several critical errata in newer Intel processors.
> 
> The updated packages being proposed in this bug report are identical to
> the ones in unstable/testing and jessie-backports, other than
> debian/changelog and version numbering.
> 
> These changes have been tested in unstable since 2016-11-09, in testing
> since 2016-11-15, and in jessie-backports since 2016-11-17, without any
> issues being reported.

Please go ahead.

Regards,

Adam

Bug#824907: ruby-reek: Fails to load library from main script

[李健秋]

Package: ruby-reek
Followup-For: Bug #824907

Thanks for reporting such issue. After replace require_relative with
relative paths with "require 'reek'" and such in bin/reek. I still
got:
/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in
`require': cannot load such file -- private_attr/everywhere
(LoadError

Does this means it missing dependency on the private_attr gem?

Best regards,
-Andrew

Bug#850214: jessie-pu: package jq/1.4-2.2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2017-01-05 at 07:12 +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> Disclaimer: I'm not a member of release team, so this is not binding
> statement :-)
> 
> On Thu, Jan 05, 2017 at 01:01:10AM -0500, Harlan Lieberman-Berg wrote:
[...]
> > +jq (1.4-2.2) jessie; urgency=high
> 
> Even though that is possible in this case, since 1.4-2.2 never in the
> archive I would suggest to use the convention 1.4-2.1+deb8u1 for the
> upload.

What Salvatore said, please. :-)

Regards,

Adam

Bug#850218: ITP: node-pinkie -- Itty bitty little widdle twinkie pinkie ES2015 Promise implementation

[Roshan]

Package: wnpp
Severity: wishlist
Owner: Roshan Nalawade 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-pinkie
  Version : 2.0.4
  Upstream Author : Vsevolod Strukchinsky  (
github.com/floatdrop)
* URL : https://github.com/floatdrop/pinkie
* License : Expat
  Programming Lang: JavaScript
  Description : Itty bitty little widdle twinkie pinkie ES2015 Promise
implementation

Bug#849020: jessie-pu: package systemd/215-17+deb8u6

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Wed, 2017-01-04 at 23:49 +0100, Cyril Brulebois wrote:
> Adam D. Barratt  (2017-01-04):
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2016-12-21 at 22:07 +0100, Michael Biebl wrote:
> > > I'd like to make a stable upload for systemd with the following changes.
> > > All the changes are cherry-picks/backports from fixes which have already
> > > been applied to systemd in unstable.
> > > 
> > > The full debdiff is attached. For better readability I will provide an
> > > annotated debian/changelog which links to the invidual commits
> > 
> > I think this looks okay (although ordering changes always make me a
> > little paranoid), and while it doesn't look like any of the changes
> > should affect the udebs or d-i, I'd still appreciate a kibi-ack.
> 
> Looks good to me indeed.

Thanks.

Michael, please feel free to upload. (I'm assuming that the resulting
package has had at least some testing on a jessie system already.)

Regards,

Adam

Bug#850217: parcimonie-applet: status icon menu is broken

[Paul Wise]

Package: parcimonie
Version: 0.10.2-4
Severity: normal
File: /etc/xdg/autostart/parcimonie-applet.desktop
Usertags: xsession-errors

When I right click the parcimonie status icon, I get this error in the systemd 
user journal:

Jan 05 14:02:19 chianamo parcimonie-applet.desktop[2708]: *** unhandled 
exception in callback:
Jan 05 14:02:19 chianamo parcimonie-applet.desktop[2708]: ***   
Gtk3::StatusIcon::position_menu: passed too few parameters (expected 4, got 2) 
at /usr/share/perl5/App/Parcimonie/Applet.pm line 161.
Jan 05 14:02:19 chianamo parcimonie-applet.desktop[2708]: ***  ignoring at 
/usr/share/perl5/Gtk3.pm line 546.

In addition, I do not get the normal right click menu with View log/Exit/About.

Also, I note that this function has been deprecated in the underlying GTK+ 
library:

https://developer.gnome.org/gtk3/stable/GtkStatusIcon.html#gtk-status-icon-position-menu

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages parcimonie depends on:
ii  dirmngr  2.1.17-2
ii  gnupg2.1.17-2
ii  gnupg2   2.1.17-2
ii  libclone-perl0.38-2+b1
ii  libconfig-general-perl   2.63-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-which-perl   1.21-1
ii  libgnupg-interface-perl  0.52-5
ii  libipc-system-simple-perl1.25-3
ii  liblist-moreutils-perl   0.416-1+b1
ii  libmoo-perl  2.002005-1
ii  libmoox-late-perl0.015-2
ii  libmoox-options-perl 4.023-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.098-1
ii  libtime-duration-parse-perl  0.13-1
ii  libtry-tiny-perl 0.27-1
ii  libtype-tiny-perl1.05-1
ii  libtypes-path-tiny-perl  0.005-1
ii  perl 5.24.1~rc4-1
ii  torsocks 2.2.0-1

Versions of packages parcimonie recommends:
pn  gnupg-curl  
ii  libglib-perl3:1.324-1
ii  libgtk3-perl0.030-1
ii  liblocale-gettext-perl  1.07-3+b1
ii  libnet-dbus-glib-perl   0.33.0-2+b1
ii  libnet-dbus-perl1.1.0-4+b1
ii  libpango-perl   1.227-1+b1
ii  libtime-duration-perl   1.20-1
ii  tor 0.2.9.8-2

parcimonie suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#850214: jessie-pu: package jq/1.4-2.2

[Salvatore Bonaccorso]

Hi

Disclaimer: I'm not a member of release team, so this is not binding
statement :-)

On Thu, Jan 05, 2017 at 01:01:10AM -0500, Harlan Lieberman-Berg wrote:
> 
> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> In order to fix two CVEs deemed not important enough for DSAs, I have prepared
> a new version of jq (1.4-2.2) for p-u.  Debdiff from version in stable is
> attached.
> 
> Can upload to s-p-u if the debdiff looks good to you.
> 

> diff -Nru jq-1.4/debian/changelog jq-1.4/debian/changelog
> --- jq-1.4/debian/changelog   2014-07-21 02:53:57.0 -0400
> +++ jq-1.4/debian/changelog   2017-01-05 00:26:08.0 -0500
> @@ -1,3 +1,11 @@
> +jq (1.4-2.2) jessie; urgency=high

Even though that is possible in this case, since 1.4-2.2 never in the
archive I would suggest to use the convention 1.4-2.1+deb8u1 for the
upload.

Regards,
Salvatore

Bug#850216: mysql-server-5.6: Listens on * by default after installation (related to use of alternatives)

[Salvatore Bonaccorso]

Source: mysql-5.6
Version: 5.6.30-1
Severity: grave
Tags: security
Justification: user security hole

Hi

When installing myssql-server-5.6 in stretch and sid, then mysqld is
started and listend not binding on localhost only, but listen on *.

tcpLISTEN 0  80 :::mysql:::*
 users:(("mysqld",pid=2810,fd=10))

This issue seems related to the switch to use the alternatives system for 
my.cnf, now mysql-5.6 as well picking the mariadb.cnf in auto mode.

That one includes

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

and thus the installation ends without

bind-address= 127.0.0.1 

Regards,
Salvatore

Bug#850214: jessie-pu: package jq/1.4-2.2

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

In order to fix two CVEs deemed not important enough for DSAs, I have prepared
a new version of jq (1.4-2.2) for p-u.  Debdiff from version in stable is
attached.

Can upload to s-p-u if the debdiff looks good to you.

diff -Nru jq-1.4/debian/changelog jq-1.4/debian/changelog
--- jq-1.4/debian/changelog	2014-07-21 02:53:57.0 -0400
+++ jq-1.4/debian/changelog	2017-01-05 00:26:08.0 -0500
@@ -1,3 +1,11 @@
+jq (1.4-2.2) jessie; urgency=high
+
+  * Non-maintainer upload.
+  * Add patch to fix CVE-2015-8863. (Closes: #802231)
+  * Add patch to fix CVE-2016-4074. (Closes: #822456)
+
+ -- Harlan Lieberman-Berg   Thu, 05 Jan 2017 00:26:08 -0500
+
 jq (1.4-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru jq-1.4/debian/patches/heap-buffer-overflow.patch jq-1.4/debian/patches/heap-buffer-overflow.patch
--- jq-1.4/debian/patches/heap-buffer-overflow.patch	1969-12-31 19:00:00.0 -0500
+++ jq-1.4/debian/patches/heap-buffer-overflow.patch	2017-01-05 00:26:08.0 -0500
@@ -0,0 +1,32 @@
+From 8eb1367ca44e772963e704a700ef72ae2e12babd Mon Sep 17 00:00:00 2001
+From: Nicolas Williams 
+Date: Sat, 24 Oct 2015 17:24:57 -0500
+Subject: [PATCH] Heap buffer overflow in tokenadd() (fix #105)
+
+This was an off-by one: the NUL terminator byte was not allocated on
+resize.  This was triggered by JSON-encoded numbers longer than 256
+bytes.
+---
+ src/jv_parse.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/jv_parse.c
 b/jv_parse.c
+@@ -172,7 +172,7 @@
+ 
+ static void tokenadd(struct jv_parser* p, char c) {
+   assert(p->tokenpos <= p->tokenlen);
+-  if (p->tokenpos == p->tokenlen) {
++  if (p->tokenpos >= (p->tokenlen - 1)) {
+ p->tokenlen = p->tokenlen*2 + 256;
+ p->tokenbuf = jv_mem_realloc(p->tokenbuf, p->tokenlen);
+   }
+@@ -271,7 +271,7 @@
+ TRY(value(p, v));
+   } else {
+ // FIXME: better parser
+-p->tokenbuf[p->tokenpos] = 0; // FIXME: invalid
++p->tokenbuf[p->tokenpos] = 0;
+ char* end = 0;
+ double d = jvp_strtod(>dtoa, p->tokenbuf, );
+ if (end == 0 || *end != 0)
diff -Nru jq-1.4/debian/patches/series jq-1.4/debian/patches/series
--- jq-1.4/debian/patches/series	2014-07-21 02:34:21.0 -0400
+++ jq-1.4/debian/patches/series	2017-01-05 00:26:08.0 -0500
@@ -4,3 +4,5 @@
 patch-version-into-build.patch
 disable-shared-lib.patch
 big-endian-fix.patch
+stack-exhaustion.patch
+heap-buffer-overflow.patch
diff -Nru jq-1.4/debian/patches/stack-exhaustion.patch jq-1.4/debian/patches/stack-exhaustion.patch
--- jq-1.4/debian/patches/stack-exhaustion.patch	1969-12-31 19:00:00.0 -0500
+++ jq-1.4/debian/patches/stack-exhaustion.patch	2017-01-05 00:26:08.0 -0500
@@ -0,0 +1,62 @@
+From 2d38a12d686a5156d4e7afb1fed7851805590582 Mon Sep 17 00:00:00 2001
+From: W-Mark Kubacki 
+Date: Fri, 19 Aug 2016 19:50:39 +0200
+Subject: [PATCH] Skip printing at MAX_DEPTH and deeper
+
+This addresses #1136, and mitigates a stack exhaustion when printing
+a very deeply nested term.
+
+Updated by hlieber...@debian.org for security backport to 1.4.
+---
+ src/jv_print.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+--- a/jv_print.c
 b/jv_print.c
+@@ -7,13 +7,17 @@
+ #include "jv_dtoa.h"
+ #include "jv_unicode.h"
+ 
++#ifndef MAX_DEPTH
++#define MAX_DEPTH 256
++#endif
++
+ #define ESC "\033"
+ #define COL(c) (ESC "[" c "m")
+ #define COLRESET (ESC "[0m")
+ 
+ // Colour table. See http://en.wikipedia.org/wiki/ANSI_escape_code#Colors
+ // for how to choose these.
+-static const jv_kind colour_kinds[] = 
++static const jv_kind colour_kinds[] =
+   {JV_KIND_NULL,   JV_KIND_FALSE, JV_KIND_TRUE, JV_KIND_NUMBER,
+JV_KIND_STRING, JV_KIND_ARRAY, JV_KIND_OBJECT};
+ static const char* const colours[] =
+@@ -99,7 +103,7 @@
+ sprintf(buf, "\\u%04x", c);
+   } else {
+ c -= 0x1;
+-sprintf(buf, "\\u%04x\\u%04x", 
++sprintf(buf, "\\u%04x\\u%04x",
+ 0xD800 | ((c & 0xffc00) >> 10),
+ 0xDC00 | (c & 0x003ff));
+   }
+@@ -124,7 +128,9 @@
+   }
+ }
+   }
+-  switch (jv_get_kind(x)) {
++  if (indent > MAX_DEPTH) {
++put_str("", F, S);
++  } else switch (jv_get_kind(x)) {
+   default:
+   case JV_KIND_INVALID:
+ assert(0 && "Invalid value");
+@@ -242,7 +248,7 @@
+   if (colour) put_str(colour, F, S);
+   put_str((flags & JV_PRINT_PRETTY) ? ": " : ":", F, S);
+   if (colour) put_str(COLRESET, F, S);
+-  
++
+   jv_dump_term(C, value, flags, indent + INDENT, F, S);
+   if (colour) put_str(colour, F, S);
+ }

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#850215: zendframework: CVE-2016-10034

[Salvatore Bonaccorso]

Source: zendframework
Version: 1.12.9+dfsg-1
Severity: grave
Tags: upstream security
Justification: user security hole

Hi,

the following vulnerability was published for zendframework.

CVE-2016-10034[0]:
| The setFrom function in the Sendmail adapter in the zend-mail
| component before 2.4.11, 2.5.x, 2.6.x, and 2.7.x before 2.7.2, and
| Zend Framework before 2.4.11 might allow remote attackers to pass
| extra parameters to the mail command and consequently execute
| arbitrary code via a \" (backslash double quote) in a crafted e-mail
| address.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10034
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10034

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

-- 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=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#849843: Pending fixes for bugs in the libyaml-libyaml-perl package

[pkg-perl-maintainers]

tag 849843 + pending
thanks

Some bugs in the libyaml-libyaml-perl package are closed in revision
d3bb9e9cdd8e70d5b021cf89365353b9b93fbc8c in branch 'master' by
Salvatore Bonaccorso

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libyaml-libyaml-perl.git/commit/?id=d3bb9e9

Commit message:

Load B::Deparse at runtime

Thanks: Eric Wong  for the report

Closes: #849843

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Jörg Frings-Fürst]

Hello Alberto,

thank you for spending your time helping to make Debian better with
this bug report.

This is a know bug in the release 0.25.1-1. 

The bug will be fixed in the next upstream release, which will be
released in mid-January.


CU
Jörg


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

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

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

Threema: SYR8SJXB

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

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


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

Bug#850213: custom package install hangs on prompts

[Antoine Beaupré]

Package: vmdebootstrap
Version: 1.7-1
Severity: normal

I *believe* that custom package installs do not properly silence
debconf prompts. I have a trivial task-* package I have built here to
enable a custom image to be more easily built and it seems to fail to
build as the custom package install hangs:

$ sudo strace -p 14530
Process 14530 attached
read(11, ^CProcess 14530 detached
 

hitting "enter" repeatedly on the vmdebootstrap terminal will make the
prompt go away, but that is *really* counter intuitive...

here's what ends up in the log when i interrupt vmdebootstrap during
this process:

2017-01-04 19:52:04 DEBUG run external command: [['chroot', '/tmp/tmpo5F5FJ', 
'dpkg', '-i', '/tmp/install_debs/task-stressant_0.1-1_amd64.deb']]
2017-01-04 19:52:05 DEBUG stdout:
1
2017-01-04 19:52:05 DEBUG stderr:
Selecting previously unselected package task-stressant.
(Reading database ... 13345 files and directories currently installed.)
Preparing to unpack .../task-stressant_0.1-1_amd64.deb ...
Unpacking task-stressant (0.1-1) ...

2017-01-04 19:52:05 DEBUG runcmd: ['chroot', '/tmp/tmpo5F5FJ', 'apt-get', '-y', 
'-f', '--no-remove', 'install'] None {}
2017-01-04 20:13:20 INFO EEEK! Something bad happened...

if i manage to be patient enough to enter in the right moment and kill
the right process at the right moment, i get *all* the output of
debootstrap dumped at once at the end.

The beginning looks like this:


Package configuration


 ┌──┤ Configuring grub-pc ├──┐
 │   │ 
 │ You chose not to install GRUB to any devices. If you continue, the boot   │ 
 │ loader may not be properly configured, and when this computer next│ 
 │ starts up it will use whatever was previously in the boot sector. If  │ 
 │ there is an earlier version of GRUB 2 in the boot sector, it may be   │ 
 │ unable to load modules or handle the current configuration file.  │ 
 │   │ 
 │ If you are already using a different boot loader and want to carry on │ 
 └ Setting up libkrb5-3:amd64 
(1.15-1) ...
Setting up libgssapi-krb5-2:amd64 (1.15-1) ...

then somewhere in there:

grub-probe: error: cannot find a device for /boot (is /dev mounted?).
grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
dpkg: error processing package grub-pc (--configure):
 subprocess installed post-installation script was killed by signal (Terminated)
dpkg: dependency problems prevent configuration of grub2:
 grub2 depends on grub-pc (= 2.02~beta3-3); however:
  Package grub-pc is not configured yet.

dpkg: error processing package grub2 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of task-stressant:
 task-stressant depends on grub2; however:
  Package grub2 is not configured yet.

dpkg: error processing package task-stressant (--configure):
 dependency problems - leaving unconfigured
cat: /proc/cmdline: No such file or directory
setupcon: The keyboard model is unknown, assuming 'pc105'. Keyboard may be 
configured incorrectly.
Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → 
/lib/systemd/system/dm-event.socket.
invoke-rc.d: could not determine current runlevel
invoke-rc.d: could not determine current runlevel
invoke-rc.d: could not determine current runlevel
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket → 
/lib/systemd/system/lvm2-lvmetad.socket.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → 
/lib/systemd/system/lvm2-lvmpolld.socket.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → 
/lib/systemd/system/lvm2-monitor.service.
cat: /proc/cmdline: No such file or directory
setupcon: The keyboard model is unknown, assuming 'pc105'. Keyboard may be 
configured incorrectly.
Errors were encountered while processing:
 grub-pc
 grub2
 task-stressant
E: Sub-process /usr/bin/dpkg returned an error code (1)

Cleaning up
Umounting /tmp/tmptyGzeK
ERROR: command failed: ['chroot', '/tmp/tmptyGzeK', 'apt-get', '-y', '-f', 
'--no-remove', 'install']
Reading package lists...
Building dependency tree...
Correcting dependencies... Done
The following additional packages will be installed:

so this looks like a grub failure of some sort... in this specific
case, i had the stupid idea of having grub as a dependency of the
meta-package...

But even without that dubious dependency, i get a prompt in the custom
package install:

root  3759  0.0  0.0  2  3888 pts/0S+   23:33   0:00  | 
  \_ sudo vmdebootstrap --serial-console --log build/vmdebootstrap.log 
--log-level debug --systemd-networkd --verbose --distribution=stretch 
--arch=amd64 --image=build/stressant-stretch-amd64.iso 

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

[gregor herrmann]

On Wed, 04 Jan 2017 08:22:46 +0100, Dominique Dumont wrote:

> > I'm just reading 
> > http://blogs.perl.org/users/steve_mynott/2017/01/rakudo-star-past-present-and-future.html
> > which mentions that Rakudo Star is moving from panda to zef.
> Thanks for the link. I'm currently trying to figure out what can be done with 
> zef:
> https://github.com/ugexe/zef/issues/117

Interesting, thanks.
 
> As for perl6-panda, I guess this package should be completely removed from 
> Debian.

Yeah, probably.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Kante: Im ersten Licht


signature.asc
Description: Digital Signature

Bug#850157: Please deprecate all ad-hoc patch systems

[Stuart Prescott]

>   Running dpkg-source -x on a source package MUST produce the source
>   of the package, ready for editing, and allow one to make changes,

The "ready for editing" language is a bit too sloppy for Policy. Ultimately 
all packages are 'ready for editing' once unpacked, it's just that you might 
be surprised by what you have to edit. 

Does 'ready for editing' mean it has to be patches-applied when unpacked? 
Does that accidentally forbid tarball-within-tarball packages? (Do we have 
any of them still or have they finally all disappeared?) 

>   and run dpkg-buildpackage to produce a modified package, without
>   taking any additional steps.

"run dpkg-buildpackage to produce a modified package" is also too loose. 
Does that mean source package or binary package? If it means binary package, 
then almost every package is non-compliant with that as a local change would 
cause dpkg-buildpackage to fail with:

dpkg-source: info: local changes detected

... of the 3.0 (quilt) source format packages, the only compliant ones would 
have "auto-commit" in debian/source/options of which there are a total of 5 
in the archive.


>>   Previously, packages which had ad-hoc patch systems would document
>>   their source code management practices in debian/README.source.
>>   Source packages now MUST NOT use in-source-package patch systems
>>   other than `3.0 (quilt)'.
> 
> How many packages in the archive would we make buggy by adding this
> requirement?  

A starting point would be "every package that build-depends on quilt or 
dpatch" of which there are 868.¹ There are 155 packages that are using some 
other patch system such as provided by CDBS.²

Since the 'patch' package is within the build-essential set, it's not easy 
to know what packages are using patch(1). There are 1159 packages that talk 
about patching things in debian/rules³ some of which are build-time commands 
and some of which are only helpers for the maintainer or comments. There are 
quite a few cases where arch-specific patches exist -- 3.0 (quilt) doesn't 
provide for arch-specific patches. I'm assuming that the proposal is not to 
drop all archs that need arch-specific patches ;) There are also build-
stage-specific patches for bootstrapping.

There are also plenty of packages that do a little sed magic in d/rules to 
alter some source prior to building. Sometimes that could be expressed as a 
patch but that patch can be very fragile (needing to be re-made on every 
single new upstream release) while the sed is not. Fiddling thing with sed 
sounds a lot like an ad hoc patch system to me and is certainly not 
something that should be forbidden.

There are a lot of packages in these lists that are maintained by 
experienced maintainers who selected these approaches for sensible technical 
reasons. Some (like simple-patchsys.mk) are relics but most are not. I think 
we're a long way from a "MUST NOT" on this sort of thing. Given the way 
packages like gcc-*, pythonX.Y and linux are operating (and many others 
besides) are operating, there needs to be an alternative that the 
maintainers consider viable first, and then a migration to that alternative.

A couple of additional points:

* Deprecating patch systems should also deprecate the 'patch' target in 
debian/rules from §4.9.

* There are still other useful roles for d/README.source documented within 
policy and in associated documents; the python modules team refer to 
README.source as the place to document that a package is not using their 
standardised tool (git-dpm) and why, for instance.

cheers
Stuart


¹ build-rdeps quilt = 760; build-rdeps dpatch = 108
² https://lintian.debian.org/tags/debian-rules-uses-deprecated-makefile.html
³ https://codesearch.debian.net/search?q=path%3Adebian%2Frules+patch


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#845075: kernel-image-4.8.0-1-armmp-di: Lamobo R1 cannot access network

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2016-11-20 at 09:20 +0100, Heinrich Schuchardt wrote:
> Package: kernel-image-4.8.0-1-armmp-di
> Version: 4.8.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I want to install Debian Stretch on my Lamobo R1 using the network
> installer.
> 
> It is unable to connect to the DHCP server.
> 
> Please, add the b53 module to the kernel.
> 
> CONFIG_B53=y
> CONFIG_B53_SPI_DRIVER=y

I think we already enabled the necessary options:

  * [armhf] dsa: Enable drivers for Lamobo R1 (aka BPi-R1): B53,
B53_MDIO_DRIVER as modules (Closes: #836231, thanks to Vagrant Cascadian)

From the device tree, it seems pretty clear that we do want
B53_MDIO_DRIVER and not B53_SPI_DRIVER.  Are you sure the installer
version you used had a verison 4.8 kernel, not 4.7?

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



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

Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3

[Ben Hutchings]

Control: tag -1 upstream

On Wed, 2016-11-23 at 09:43 +0100, Michael Stapelberg wrote:
[...]
> However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I
> noticed that the kernel can’t find any block devices (and hence no root file
> system). This is because the bcm2835-sdhost MMC driver has not actually made 
> it
> into Linux 4.8; it is still under review:
> https://www.spinics.net/lists/arm-kernel/msg513433.html
[...]

As this is still the case, we won't add the driver yet.  Please let us
know when it is accepted upstream, and we can consider backporting that
version for stretch.

Besides which, we already enable the sdhci-iproc driver which should
also work on the RPi 3.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



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

Bug#850212: lxc: lxc init script should depend on cgroupfs-mount

[Benda Xu]

Package: lxc
Version: 1:2.0.6-1~bpo8+1
Severity: important

Dear Maintainer,

lxc requires cgroupfs to be properly mounted.  This task is either done by
cgroupfs-mount init script or systemd.  The former does nothing if started
by systemd:

  # Test for systemd and bail (we have to test before sourcing init-functions, 
or systemd hijacks us)
  # We bail because systemd already mounts cgroups sanely, so we just silently 
pretend we were successful in mounting them here
  if [ -d /run/systemd/system ]; then
  exit 0
  fi

Therefore adding cgroupfs-mount to the service dependency of lxc fix startup
issue on non-systemd systems.

  ### BEGIN INIT INFO
  # Provides: lxc
  # Required-Start: $syslog $remote_fs cgroupfs-mount
  # Required-Stop: $syslog $remote_fs cgroupfs-mount

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lxc depends on:
ii  init-system-helpers  1.29
ii  libapparmor1 2.9.0-3
ii  libc62.24-4
ii  libcap2  1:2.24-8
ii  liblxc1  1:2.0.6-1~bpo8+1
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  lsb-base 4.1+Debian13+nmu1
ii  python3-lxc  1:2.0.6-1~bpo8+1
pn  python3:any  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-9
ii  debootstrap   1.0.67
ii  dirmngr   2.1.16-3
ii  dnsmasq-base  2.72-3+deb8u1
ii  gnupg 2.1.16-3
ii  iptables  1.4.21-2+b1
pn  libpam-cgfs   
pn  lxcfs 
ii  openssl   1.0.1t-1+deb8u5
ii  rsync 3.1.1-3
pn  uidmap

Versions of packages lxc suggests:
pn  apparmor 
ii  btrfs-tools  4.7.3-1~bpo8+1
ii  lvm2 2.02.111-2.2+deb8u1

-- Configuration Files:
/etc/apparmor.d/lxc/lxc-default [Errno 2] No such file or directory: 
u'/etc/apparmor.d/lxc/lxc-default'
/etc/apparmor.d/lxc/lxc-default-with-mounting [Errno 2] No such file or 
directory: u'/etc/apparmor.d/lxc/lxc-default-with-mounting'
/etc/init.d/lxc changed:
log_daemon_msg () {
echo $@
}
test ! -r /lib/lsb/init-functions ||
. /lib/lsb/init-functions
start() {
# Setup host /dev for autodev containers.
log_daemon_msg "Starting LXC autoboot containers: "
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers start
}
stop() {
log_daemon_msg "Stopping LXC containers: "
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers stop
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload|force-reload)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart|reload|force-reload}"
exit 2
;;
esac
exit $?

/etc/lxc/default.conf [Errno 2] No such file or directory: 
u'/etc/lxc/default.conf'

-- no debconf information
diff --git a/init.d/lxc b/init.d/lxc
index 1205d8c..e2e620a 100755
--- a/init.d/lxc
+++ b/init.d/lxc
@@ -7,8 +7,8 @@
 #
 ### BEGIN INIT INFO
 # Provides: lxc
-# Required-Start: $syslog $remote_fs
-# Required-Stop: $syslog $remote_fs
+# Required-Start: $syslog $remote_fs cgroupfs-mount
+# Required-Stop: $syslog $remote_fs cgroupfs-mount
 # Should-Start:
 # Should-Stop:
 # Default-Start: 2 3 4 5

Bug#847570: linux-image-4.9.0-rc8-amd64-unsigned: AMDGPU not build with support for GCN1.0 and GCN1.1 VGAs

[Ben Hutchings]

On Fri, 2016-12-09 at 16:06 +0100, Ferdinand Pöll wrote:
> Package: linux-image-4.9.0-rc8-amd64-unsigned
> Version: 4.9~rc8-1~exp1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainer,
> 
> I have an AMD Radeon R9 270X and I'd like to use the new amdgpu driver with 
> it.
> Since 4.9, linux includes experimental support for GCN 1.0 VGAs, but it's not
> enabled in the debian builds as well as the support for GCN 1.1 cards (which
> isn't new in the kernel anymore). In the kernel build config, you just need to
> set CONFIG_DRM_AMDGPU_SI=Y (for GCN1.0-based cards) and 
> CONFIG_DRM_AMDGPU_CIK=Y
> (for GCN1.1-based cards). To use amdgpu if it is built into the kernel with 
> the
> old gpus users just need to blacklist radeon and upon the next reboot linux
> will load amdgpu and users can install amdgpu-pro if they want to or just 
> stick
> with the newest free graphics driver.

I don't think this will work the way you expect.  kmod will load both
modules unless one of them is blacklisted, and it's not documented
which one will be tried first.  So we could end up loading amdgpu on
systems that should still be using radeon by default.

We could perhaps patch amdgpu so that it isn't auto-loaded for the GCN
1.0 GPUs.  But I'm not yet convinced this is worth doing.

Ben.

> The kernel in my system info below is built from source with the options
> mentioned above enabled.


-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



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

Bug#850211: open-iscsi: Boot with systemd hangs for iSCSI+LUKS+LVM volume

[Abhijit Menon-Sen]

Package: open-iscsi
Version: 2.0.874-1~bpo8+1
Severity: normal

Dear Maintainer,

I have a NAS that exports an iSCSI target. I have created a LUKS volume
on a partition on this target, used that volume as a PV, and created an
LVM VG/LV on top of it. On boot, systemd waits for 90s for the iSCSI
device and its subsidiary devices to appear before bringing up the
network. This is similar to bug #775778.

I am not sure that this is a bug in open-iscsi, but I'm filing it here
on the basis of the strong similarity with #775778. (I'm running jessie
with updates from jessie-backports, so I have the patches from that bug
already.)

This is how I setup my volume:

# The iSCSI part works fine.
iscsiadm … --login

# Device shows up as /dev/sdb; I create a /dev/sdb1 partition using
# fdisk, of type 8e.

# Create encrypted LUKS volume on /dev/sdb1, open and map as
# /dev/mapper/sdb1_crypt.
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 sdb1_crypt \
--key-file /root/blackbird-ullu

# Set up LVM PV, VG, and LV mapped to /dev/mapper/blackbird-ullu,
# with an ext4 filesystem on top.
pvcreate /dev/mapper/sdb1_crypt
vgcreate blackbird /dev/mapper/sdb1_crypt
lvcreate -n ullu -l 100%VG blackbird
mkfs.ext4 /dev/mapper/blackbird-ullu

mount /dev/mapper/blackbird-ullu /media/nas

I have an entry in /etc/crypttab like this:

sdb1_crypt UUID=ae6b9263-d63c-4515-b7ce-51e5cc4caa9f /root/blackbird-ullu 
luks

And an entry in /etc/fstab like this (I've tried various variants here,
see below):

/dev/mapper/blackbird-ullu /media/nas ext4 defaults,nofail,_netdev 0 6

There are three devices involved:

- /dev/disk/by-uuid/: is the iSCSI target (/dev/sdb)
- /dev/mapper/sdb1_crypt: result of cryptsetup luksOpen /dev/sdb1 
- /dev/mapper/blackbird-ullu: LV built on top of sdb1_crypt

Now I suffer from the 90s wait on startup (before network-online), where
systemd waits for the dev-mapper-blackbird\x2dullu.device to become
available, along with dev-disk-by\x2duuid-.device and
dev-mapper-sdb1_crypt.device.

After the timeout, the boot proceeds, brings up the network, starts
iscsid, and runs /lib/open-iscsi/activate-storage.sh once /dev/sdb is
available, but the "vgchange -aay" command fails because the PV is not
yet mapped with cryptsetup:

activate-storage.sh[2618]:   Volume group "blackbird" not found
activate-storage.sh[2618]:   Skipping volume group blackbird
activate-storage.sh[2618]: Warning: could not activate all LVM groups.

This is the first time I have used iSCSI or systemd, so my attempts to
resolve this are pretty amateurish, but here's an overview:

(a) I shortened the 90s timeout for all three devices by creating
drop-in overrides for the corresponding .device units under
/etc/systemd/system:


dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device.d/nowait.conf
dev-mapper-sdb1_crypt.device.d/nowait.conf
dev-mapper-blackbird\x2dullu.device.d/nowait.conf

[Unit]
JobTimeoutSec=1

(I later removed the third file and instead added the
x-systemd.device-timeout=1s mount flag in /etc/fstab for the
/dev/mapper/blackbird-ullu volume, but this is functionally equivalent
to the above.)

After this, the boot proceeded with only a 1s wait, with messages like this:

systemd[1]: dev-mapper-sdb1_crypt.device: Job 
dev-mapper-sdb1_crypt.device/start timed out.
systemd[1]: Timed out waiting for device dev-mapper-sdb1_crypt.device.
systemd[1]: Dependency failed for Cryptography Setup for sdb1_crypt.
systemd[1]: Dependency failed for Encrypted Volumes.
systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with 
result 'dependency'.
systemd[1]: systemd-cryptsetup@sdb1_crypt.service: Job 
systemd-cryptsetup@sdb1_crypt.service/start failed with result 'dependency'.
systemd[1]: dev-mapper-sdb1_crypt.device: Job 
dev-mapper-sdb1_crypt.device/start failed with result 'timeout'.
systemd[1]: 
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device: 
Job dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa
systemd[1]: Timed out waiting for device 
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device.
systemd[1]: 
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device: 
Job dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa
systemd[1]: dev-mapper-blackbird\x2dullu.device: Job 
dev-mapper-blackbird\x2dullu.device/start timed out.
systemd[1]: Timed out waiting for device 
dev-mapper-blackbird\x2dullu.device.
systemd[1]: Dependency failed for /media/nas.
systemd[1]: media-nas.mount: Job media-nas.mount/start failed with result 
'dependency'.
systemd[1]: Dependency failed for File System Check on 
/dev/mapper/blackbird-ullu.
systemd[1]: systemd-fsck@dev-mapper-blackbird\x2dullu.service: Job 

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

Thanks for the starting point. I had worked out the d/watch file enough
that it works locally (mentors.debian.net still complains), but I like your
wildcards better, so I'm using that one (mentors.debian.net still
complains). The simple short d/rules is very much appreciated. I only just
begin to discover the override_* stuff before you sent it. You saved me two
days there. That and writing d/install and d/clean exposed some
embarrassing stray symbolic links. I actually prefer enumerating the exact
placement of all the files. So, what remains:

 - I think the fortify complaint about slave and stubslave is probably
because they are so minimal. I don't think they use any libc functions
actually.
 - There's no obvious override for the duplicate changelog warning.
 - Revisit d/changelog to make sure the package changes are fully captured.
 - It would be nice to get make -j2 working. They did work once upon a
time. Might be better to fix that upstream.
 - Test. The prettiest package in the world doesn't necessarily install
anything that works.

On Wed, Jan 4, 2017 at 4:32 PM, Tobias Frost  wrote:

> Am Donnerstag, den 05.01.2017, 00:24 +0100 schrieb Tobias Frost:
> >
> > I wrote you a rule file as starting point. Attached. It is thought to
> > get you started.
> > (Some parts are missing, like the hardening; also stuff and you need
> > to
> > do outside of the rules, like to create the file d/clean with all
> > files
> > listed and d/install to to put the files actually in place
> >
> PS: I needed to add --no-parallel because parallel build is broken
> here. This is also bug in your Makefile...
>
> To trigger
> #debuild -j1
> (works)
>
> #debuild -j4
> (...)
> g++ -g -O2 -fdebug-prefix-
> map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o stubslave stubslave.o -L.
> -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux
> collect2: error: ld returned 1 exit status
> Makefile:189: recipe for target 'stubslave' failed
> make[1]: *** [stubslave] Error 1
> make[1]: *** Waiting for unfinished jobs
> ( if [ -f netmux ]; then mv -f netmux netmux~ ; fi )
> g++ -g -O2 -fdebug-prefix-
> map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o netmux _build.o alarm.o
> alloc.o attrcache.o boolexp.o bsd.o command.o comsys.o conf.o cque.o
> create.o db.o db_rw.o eval.o file_c.o flags.o funceval.o funceval2.o
> functions.o funmath.o game.o help.o htab.o local.o log.o look.o mail.o
> match.o mathutil.o mguests.o modules.o move.o muxcli.o netcommon.o
> object.o predicates.o player.o player_c.o plusemail.o powers.o quota.o
> rob.o pcre.o set.o sha1.o speech.o stringutil.o strtod.o svdrand.o
> svdhash.o timer.o timeabsolute.o timedelta.o timeparser.o timeutil.o
> timezone.o unparse.o utf8tables.o vattr.o walkdb.o wild.o
> wiz.o  version.o -L. -lm -lcrypt -lmux
> /usr/bin/ld: cannot find -lmux
> collect2: error: ld returned 1 exit status
> Makefile:198: recipe for target 'netmux' failed
> make[1]: *** [netmux] Error 1
> make[1]: Leaving directory
> '/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13/src'
>

Bug#692754: how to get the username in the plugin?

[Ron]

On Thu, Jan 05, 2017 at 12:47:07PM +1030, Ron wrote:
> On Thu, Jan 05, 2017 at 08:34:04AM +1100, martin f krafft wrote:
> > also sprach Johannes Berg  [2017-01-05 01:11 
> > +1100]:
> > > I'm not even sure how to get the username? Is it even generally
> > > possible, if e.g. the plugin is running out of a process that's not
> > > invoked through the imapd?
> > 
> > Well, the plugin certainly does seem to be run as the target user,
> > or else how could it be used for user-specific training?
> 
> There's probably a lot of things we _could_ do ...
> 
> In the most general case getpwuid_r(geteuid(),...) should tell us who we
> are running as, no matter how we are run - but that has potential icky,
> since getting that name could involve a network access to LDAP or worse.
> 
> I'm not sure offhand if dovecot already (reliably) exposes it to us in
> the environment we get from it - docs on that didn't pop out at me ...
> 
> Or worst case, we could make one, and let people do something like:
> 
>  antispam_log_prefix = %u
> 
> in their config, since dovecot will expand the %u for us ...
> That has the advantage of letting them customise it if they have some
> really crazy setup with multiple dovecot instances all logging to the
> same place ...
> 
> 
> But all of this kind of sets my XY problem overkill alarm off in a
> variety of ways, so I think we ought to actually start at the top:
> 
> Martin, what _actual_ problem did you have to make you want this?
> That might be something we can (also?) fix better and simpler?

Just to be clear, there's a lot of permutations here about what
backend might be run (and you didn't say which you are using),
and usually the only case where the user might actually matter,
we're passing that user to an external program (and don't have
any control over what it outputs) ...

So in most of what -antispam might log, any failure isn't going
to be due to something "user specific" - which means it would be
good to know exactly what problem you hit that (you thought?) was.

Otherwise, this could just turn into lots of intrusive busywork
that doesn't actually solve it, if we don't know what "it" was.

  Ron

Bug#850210: RM: freqtweak -- RoQA; unmaintained, RC buggy, dead upstream

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Please remove the freqtweak package. It is orphaned (#846810), upstream
is not active anymore and it blocks the removal of libsigc++-1.2 See
#672390 and #738897 for further details.

Thanks,
Michael

Bug#850209: Recommends needed to be re-thinked

[Alf Gaida]

Package: lxqt
Version: 9
Severity: normal

Recommends: cmst, connman | network-manager is not the best of all ideas,
especially if connman and cmst don't make it into stable. Second cmst depends
on connman - so the connman dependency is super-fluous. Same for
network-manager - networkmanager-gnome depends on network-manager, so 
cmst | network-manager-gnome | ifupdown is much cleaner.

 In case connman shouldn't make it into stretch it should be:

Recommends: network-manager-gnome | cmst | ifupdown, ...

in case connman goes in it should be:

Recommends: cmst | network-manager-gnome | ifupdown, ...

Sounds like a crazy idea at first glance, but the nm-applet and and the config
editor just work fine with LXQt and esp. lxqt-panel. 

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

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

Versions of packages lxqt depends on:
ii  lxqt-about0.11.1-1
ii  lxqt-admin0.11.1-1
ii  lxqt-config   0.11.1-1
ii  lxqt-core 9
ii  lxqt-globalkeys   0.11.1-1
ii  lxqt-notificationd0.11.1-1
ii  lxqt-openssh-askpass  0.11.1-1
ii  lxqt-policykit0.11.1-1
ii  lxqt-powermanagement  0.11.1-1
ii  lxqt-qtplugin 0.11.2~1-g63da0ff-2
ii  lxqt-runner   0.11.1-1

Versions of packages lxqt recommends:
ii  audacious   3.7.2-2
ii  cmst2016.10.03-20-g390231f-4
ii  connman 1.34~692-gf07aea37-2
ii  firefox [www-browser]   50.1.0-1
ii  gksu2.0.2-9
ii  google-chrome-stable [www-browser]  54.0.2840.59-1
ii  gucharmap   1:9.0.2-1
ii  links [www-browser] 2.14-1
ii  lximage-qt  0.5.1-1
ii  lxqt-sudo   0.11.1-1
ii  pavucontrol-qt  0.2.1~1-gd188fa9-1
ii  qlipper 1:5.0.1~13-g14bfc66-1
ii  qpdfview0.4.15-1
ii  qps 1.10.16-29-g7e679db-2
ii  qterminal   0.7.1-2
ii  sddm [x-display-manager]0.14.1~25-g38ce346-1
ii  smplayer16.11.0~ds0-1
ii  smtube  15.5.10-1
ii  xarchiver   1:0.5.4-6

Versions of packages lxqt suggests:
pn  calibre 
ii  claws-mail  3.14.1-2
pn  compton 
pn  compton-conf
ii  juffed  0.10-85-g5ba17f9-10
ii  nomacs  3.4.1-38-g60c8281-1
pn  obconf-qt   
pn  openbox 
pn  qtpass  
pn  quassel | quassel-client | hexchat  
ii  screengrab  1.96-1
ii  vokoscreen  2.5.2~9-gd9b9b33-1
ii  zim 0.65-4

-- no debconf information

Bug#692754: how to get the username in the plugin?

[Ron]

On Thu, Jan 05, 2017 at 08:34:04AM +1100, martin f krafft wrote:
> also sprach Johannes Berg  [2017-01-05 01:11 
> +1100]:
> > I'm not even sure how to get the username? Is it even generally
> > possible, if e.g. the plugin is running out of a process that's not
> > invoked through the imapd?
> 
> Well, the plugin certainly does seem to be run as the target user,
> or else how could it be used for user-specific training?

There's probably a lot of things we _could_ do ...

In the most general case getpwuid_r(geteuid(),...) should tell us who we
are running as, no matter how we are run - but that has potential icky,
since getting that name could involve a network access to LDAP or worse.

I'm not sure offhand if dovecot already (reliably) exposes it to us in
the environment we get from it - docs on that didn't pop out at me ...

Or worst case, we could make one, and let people do something like:

 antispam_log_prefix = %u

in their config, since dovecot will expand the %u for us ...
That has the advantage of letting them customise it if they have some
really crazy setup with multiple dovecot instances all logging to the
same place ...


But all of this kind of sets my XY problem overkill alarm off in a
variety of ways, so I think we ought to actually start at the top:

Martin, what _actual_ problem did you have to make you want this?
That might be something we can (also?) fix better and simpler?

  Ron

Bug#738897: RM libsigc++-1.2

[Scott Kitterman]

>At this point it's probably safe to assume that freqtweak won't be
>fixed.
>
>The package is orphaned [1] and dead upstream (last upstream activity
>is
>over 7 years ago [2]).
>Please remove it along with libsigc++-1.2.

Please file a separate rm bug for it.

Scott K

Bug#850208: Missing category in Netsurfs desktop file

[Joerg Schiermeier, Bielefeld/Germany]

Package: netsurf-gtk
Version: 3.2+dfsg-2+b1
Severity: normal

Hello!

Netsurfs desktop file "netsurf-gtk.desktop" is missing one category which evry 
browsers desktop file has: WebBroser.
To illustrate this I copy an example from actual package 
"netsurf-gtk_3.6-3_amd64.deb" into this report.

>From "netsurf-gtk.desktop", please look at this:
Icon=netsurf.png
Categories=Network;
^^
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;image/gif;image/jpeg;image/png

The categories should be like:
Categories=Network;WebBrowser;

Thanks for your attention!

-- 

Kindly regards
Joerg Schiermeier
Bielefeld/Germany




-- System Information:
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: SolydXK
Description:SolydK 8 64-bit
Release:8
Codename:   solydxk
Architecture: x86_64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 netsurf-gtk depends on:
ii  libc62.23-4
ii  libcairo21.14.0-2.1+deb8u1
ii  libcurl3 7.38.0-4+deb8u5
ii  libexpat12.1.0-6+deb8u3
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libjpeg62-turbo  1:1.3.1-12
ii  libmozjs185-1.0  1.8.5-1.0.0+dfsg-4.3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpng12-0   1.2.50-2+deb8u2
ii  librsvg2-2   2.40.5-1+deb8u2
ii  libssl1.0.0  1.0.1t-1+deb8u5
ii  netsurf-common   3.2+dfsg-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages netsurf-gtk recommends:
ii  mime-support  3.58

netsurf-gtk suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/applications/netsurf-gtk.desktop (from 
netsurf-gtk package)

Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Jens Reyer]

On 05.01.2017 02:03, Jens Reyer wrote:
> I will probably commit this tomorrow. We may add some information to the
> README about this, and how to create an association manually.

Alternatively we may change wine.inf (drop "-a") which should help
normally (?) to prevent native associations, *and* do the blacklisting
for file types so that if this is still triggered by e.g. installing
Foxit Reader at least not too many associations are created.

This way anybody preferring the old behavior could just manually run
"winemenubuilder -a" to create all not-blacklisted associations.

I'd blacklist all extensions for which Wine always creates associations,
presumably:
pdf
rtf
xml
gif
jfif
jpe
jpeg
png
htm
html
txt
url
wri - application/x-mswrite=libreoffice-writer.desktop
msp - Microsoft Paint Image (in Windows 2.0), or
  application/mspowerpoint=libreoffice-impress.desktop
vbs - Visual Basic Script
vbs - Visual Basic Script
ini - open with notepad or with native editor?


Except maybe these:
chm - Compiled HTML Help is the standard help system for Windows.
hlp - Microsoft Windows Help file.

Bug#850207: flightgear: Fresh install of 2016.4.3 does not work with dependent packages

[Daren Beattie]

Package: flightgear
Version: 1:2016.4.3+dfsg-2
Severity: important

Dear Maintainer,

I installed a fresh copy of flightgear a day or two ago, along with its 
dependencies. The version on the main flightgear package is 2016.4.3, but all 
dependencies are version 2016.4.2. The flightgear startup dialog asked for the 
path to the data files. After a bit of googling and checking my system, I 
pointed it to /usr/share/games/flightgear. The dialog then complained "The 
chosen location (/usr/share/games/flightgear) contains files for version 
2016.4.2, but this is FlightGear 2016.4.3. Please update or try another 
location".
I have not tried downloading a copy of the 2016.4.3 data from upstream. 
Presumably that would work, but I would prefer that the flightgear package 
dependencies be as strict as the game itself is, so that the installed game 
works as-is.


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

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

Versions of packages flightgear depends on:
ii  flightgear-data-all   1:2016.4.2+dfsg-1
ii  freeglut3 2.8.1-3
ii  libc6 2.24-8
ii  libcurl3-gnutls   7.51.0-1
ii  libdbus-1-3   1.10.14-1
ii  libexpat1 2.2.0-1
ii  libflite1 2.0.0-release-3
ii  libgcc1   1:6.2.1-5
ii  libgl1-mesa-glx [libgl1]  13.0.2-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgsm1   1.0.13-4
ii  libhtsengine1 1.08-1
ii  libice6   2:1.0.9-1+b1
ii  libopenal11:1.17.2-4
ii  libopenscenegraph100v53.2.3+dfsg1-2+b2
ii  libopenthreads20  3.2.3+dfsg1-2+b2
ii  libplib1  1.8.5-7
ii  libpng16-16   1.6.26-6
ii  libqt5core5a  5.7.1+dfsg-1
ii  libqt5gui55.7.1+dfsg-1
ii  libqt5widgets55.7.1+dfsg-1
ii  libsm62:1.2.2-1+b1
ii  libspeex1 1.2~rc1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libsqlite3-0  3.15.2-2
ii  libstdc++66.2.1-5
ii  libudev1  232-8
ii  libudns0  0.4-1
ii  libx11-6  2:1.6.4-2
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.8-1
ii  libxmu6   2:1.1.2-2
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages flightgear recommends:
ii  flightgear-phi  2016.4.2+dfsg1-1

flightgear suggests no packages.

-- no debconf information

Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress

[Brian May]

Brian May  writes:

> Not sure if I can git push to the openstack git repository, so I haven't
> done so (and I might have to redo it anyway). If I can get this working,
> I might move it to DPMT.

Ok, just building and uploading.

Note that this isn't going to really help, there are 2 RC bugs against
faker, which this package depends on.
-- 
Brian May 

Bug#850206: debootstrap output not available

[Antoine Beaupré]

Package: vmdebootstrap
Version: 1.7-1
Severity: minor

In newer vmdeboostrap versions, I am not sure since when, debootstrap
output is hidden from view when launched. This makes it frustratingly
hard to figure out what is going on when an image is built.

For example, while building a stretch image here, I got this:

Creating disk image
Creating partitions
Creating filesystem ext4
Mounting /dev/mapper/loop2p1 on /tmp/tmpo5F5FJ
Debootstrapping stretch [amd64]
[...]

The "[...]" happened to hang because of a custom package I added to
the build, but I had no way to tell. It's only after 10+ minutes that
I started to wonder if something was wrong, and I had to dig through
piles of ps axfwu, strace -p and lsof -p to try and understand what
was happening.

It would be nice if the output was logged somewhere. I expected it to
be on stderr or somewhere visible, or at least in the logfile (which I
enabled with --log and --log-level debug).

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

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

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.67
ii  kpartx  0.5.0-6+deb8u2
ii  libjs-sphinxdoc 1.4.6-1~bpo8+1
ii  parted  3.2-7
ii  python-cliapp   1.20150829-1~bpo8+1
ii  python-distro-info  0.14
ii  python2.7   2.7.9-2+deb8u1
pn  python:any  
ii  qemu-utils  1:2.1+dfsg-12+deb8u6

Versions of packages vmdebootstrap recommends:
ii  dosfstools3.0.27-1
ii  extlinux  3:6.03+dfsg-5+deb8u1
ii  grub2-common  2.02~beta2-22+deb8u1
ii  python-guestfs1:1.28.1-1
ii  qemu-system   1:2.1+dfsg-12+deb8u6
ii  qemu-user-static  1:2.1+dfsg-12+deb8u6
ii  squashfs-tools1:4.2+20130409-2

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
ii  mbr   1.1.11-5+b1
ii  pandoc1.12.4.2~dfsg-1+b14
pn  u-boot:armhf  

-- no debconf information

Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Jens Reyer]

Thanks everyone for the feedback! I've been digging through this today.

On 04.01.2017 21:11, Stephen Kitt wrote:
> On Tue, 3 Jan 2017 09:06:21 -0500, Michael Gilbert 
> wrote:
>> On Tue, Jan 3, 2017 at 8:49 AM, Jens Reyer wrote:
>>> This meets my personal preference. What do others think?  
>>
>> In the long term, I think we'll end up needing to blacklist all
>> extensions with this approach.
>>
>> I'm ok with it as a temporary solution for stretch, but the ideal
>> approach would only create the files when the user explicitly tells
>> winemenubuilder to do it, rather than automatically during install,
>> upgrade, etc when the user hasn't asked for it.
> 
> I've come across http://askubuntu.com/questions/323437 which suggests a
> simpler solution: dropping the "-a" switch from the winemenubuilder.exe
> command-line in wine.inf. I haven't tried this out (yet) so I don't know if
> it affects file associations inside Wine.

I just tested this in a clean environment[1], but unfortunately it
doesn't work as required:

I created a fresh prefix and installed an application. This used to
cause the generation of the unwanted native associations, but didn't
happen now - good. And the Windows application still opened pdf's with
evince (native default for pdf).

But then I installed Foxit Reader and suddenly had the whole bunch of
native associations (pdf, htm, txt, ...).

I have verified in the code that the code which generates those is
indeed only called from "winemenubuilder -a"[2].
So it looks as if something calls "winemenubuilder -a" explicitly
(wine.inf probably only changes the default). Or is that a bug in Wine
(I'll ask upstream/file a bug)?




Then I tested to force this behavior, by making the -a switch a no-op[3]:

CAVEAT 1: This removes the option to run "winemenubuilder -a" manually
(or ignores the -a switch when doing so)! - Bad, but acceptable?

Besides that I think only the functions described in [2] are affected (=
not called), so I assume there are no side effects.

The unwanted native general purpose .desktop entries are not created.

Installing an app creates as usual its launchers on the desktop and some
specific ones in ~/.local/share/applications/wine/Programs.  Further
icons and menus/desktop-directories in ~/.local/share and ~/config.

The installed app correctly used evince for opening a pdf.

Installing Foxit Reader this time didn't generate all the unwanted
native associations (neither for pdf nor for anything else). Good.

The other app then used Foxit Reader for opening a pdf. But native apps
didn't. Good.

CAVEAT 2: Of course this also means that a file type association that is
not available natively, will still not be created if you install a
Windows applications which provides it. This would also be a problem if
changing wine.inf worked. - On the other side, many (me including) will
prefer this behavior, because they don't want Wine to touch their system
at all.

I will probably commit this tomorrow. We may add some information to the
README about this, and how to create an association manually.



Otherwise: I had missed to place the full list of extensions in my
previous patch. But basically I planned to blacklist nearly all
extensions for which Wine always creates associations (except a few ones
which seem to be Windows specific and don't have a native association
(on my system)).




[1]
Warning, this might also remove unrelated content:
rm -rf ~/.wine ~/.local/share/applications/
~/.local/share/desktop-directories/ ~/.local/share/icons/
~/.local/share/mime/ ~/.config/menus/applications-merged/


[2]
The function
 write_freedesktop_association_entry
and (not sure if it really affects my system)
 write_freedesktop_mime_type_entry
create the problematic entries.

They are *only* called from
 generate_associations
which is the only place where
 is_extension_blacklisted
(which I used in my previous patch) is used. generate_associations has
no other function.

generate_associations is *only* called from
 RefreshFileTypeAssociations (line 3332)
which is *only* called from
 wWinMain (line 3641)
and only if the "-a" switch is used.


[3]
+--- a/programs/winemenubuilder/winemenubuilder.c
 b/programs/winemenubuilder/winemenubuilder.c
+@@ -3638,7 +3638,6 @@ int PASCAL wWinMain (HINSTANCE hInstance
+   break;
+ if( !strcmpW( token, dash_aW ) )
+ {
+-RefreshFileTypeAssociations();
+ continue;
+ }
+ if( !strcmpW( token, dash_rW ) )

Bug#850205: automatic serial console configuration for jessie and above

[Antoine Beaupré]

Package: vmdebootstrap
Version: 1.7-1
Severity: wishlist

I see that in #800910 the --serial-console flag has been basically
disabled for platforms other than wheezy. That's fine to resolve the
bug described there (although I agree the fix should be sysvinit
specific), but it actually removes an interesting feature for newer
platforms.

I think vmdebootstrap should remove the --serial-console flag or make
it work in newer releases. In systemd, the way to configure the serial
console is to pass the serial port on the kernel commandline, as such:

GRUB_CMDLINE_LINUX="console=ttyS0"

Then systemd automatically picks it up and configures a getty on the
right port. More details here:

https://wiki.debian.org/systemd#Virtual_and_serial_console_changes

I am not sure how to do it myself in the vmdebootstrap
environment. Maybe it is trivial to add grub flags, but I didn't find
an easy way to do this. I feel hesitant in making a script that
will just overwrite the kernel commandline directly, as vmdebootstrap
may already deal with this file in its own ways...

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

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

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.67
ii  kpartx  0.5.0-6+deb8u2
ii  libjs-sphinxdoc 1.4.6-1~bpo8+1
ii  parted  3.2-7
ii  python-cliapp   1.20150829-1~bpo8+1
ii  python-distro-info  0.14
ii  python2.7   2.7.9-2+deb8u1
pn  python:any  
ii  qemu-utils  1:2.1+dfsg-12+deb8u6

Versions of packages vmdebootstrap recommends:
ii  dosfstools3.0.27-1
ii  extlinux  3:6.03+dfsg-5+deb8u1
ii  grub2-common  2.02~beta2-22+deb8u1
ii  python-guestfs1:1.28.1-1
ii  qemu-system   1:2.1+dfsg-12+deb8u6
ii  qemu-user-static  1:2.1+dfsg-12+deb8u6
ii  squashfs-tools1:4.2+20130409-2

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
ii  mbr   1.1.11-5+b1
ii  pandoc1.12.4.2~dfsg-1+b14
pn  u-boot:armhf  

-- no debconf information

Bug#849749: [reportbug/master] port bug script and control file to py3k; patch by Nis Martensen; Closes: #849749

[Sandro Tosi]

tag 849749 pending
tag 849749 pending
thanks

Date:   Wed Jan 4 19:46:54 2017 -0500
Author: Sandro Tosi 
Commit ID: 42181e036d0efe54d73e92ec9f90dec00fea297e
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=42181e036d0efe54d73e92ec9f90dec00fea297e
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=42181e036d0efe54d73e92ec9f90dec00fea297e

port bug script and control file to py3k; patch by Nis Martensen; Closes: 
#849749

  

Bug#849677: [reportbug/master] capitalize, not uppercase, ampersend user replacement; patch by Nis Martensen; Closes: #849677

[Sandro Tosi]

tag 849677 pending
tag 849677 pending
thanks

Date:   Wed Jan 4 19:51:57 2017 -0500
Author: Sandro Tosi 
Commit ID: 6869191bb7a1e518f86ee05a56f8f2f39ade6e57
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=6869191bb7a1e518f86ee05a56f8f2f39ade6e57
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=6869191bb7a1e518f86ee05a56f8f2f39ade6e57

capitalize, not uppercase, ampersend user replacement; patch by Nis 
Martensen; Closes: #849677

  

Bug#848692: [reportbug/master] fix the 'email' name clash in reportbug.utils functions by renaming their arguments to 'emailaddr', this fixes names with special characters in the address; patch by Did

[Sandro Tosi]

tag 848692 pending
tag 848692 pending
thanks

Date:   Wed Jan 4 19:18:56 2017 -0500
Author: Sandro Tosi 
Commit ID: e5dc19b88f1e2a5e99a507fbc21505b44af2ff7e
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=e5dc19b88f1e2a5e99a507fbc21505b44af2ff7e
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=e5dc19b88f1e2a5e99a507fbc21505b44af2ff7e

fix the 'email' name clash in reportbug.utils functions by renaming their 
arguments to 'emailaddr', this fixes names with special characters in the 
address; patch by Didier 'OdyX' Raboud; Closes: #848692

  

Bug#848655: [reportbug/master] use integer division when computing the max length for a name; suggestion by Ben Longbons; Closes: #848655

[Sandro Tosi]

tag 848655 pending
tag 848655 pending
thanks

Date:   Wed Jan 4 19:40:33 2017 -0500
Author: Sandro Tosi 
Commit ID: ca3f62a98591d24c2b1600a88fed692c3f6b4317
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=ca3f62a98591d24c2b1600a88fed692c3f6b4317
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=ca3f62a98591d24c2b1600a88fed692c3f6b4317

use integer division when computing the max length for a name; suggestion 
by Ben Longbons; Closes: #848655

  

Bug#850106: guile-2.0-dev: Uninstallable due to unmeetable dependencies

[Rob Browning]

Michael Vehrs  writes:

> Aptitude says:
>
> The following packages have unmet dependencies:
>libtinfo-dev : Depends: libtinfo5 (= 5.9+20140913-1+b1) but 
> 6.0+20151024-2 is installed.
>libncurses5-dev : Depends: libtinfo5 (= 5.9+20140913-1+b1) but 
> 6.0+20151024-2 is installed.
>  Depends: libncurses5 (= 5.9+20140913-1+b1) but 
> 6.0+20151024-2 is installed.

I'm not sure why you're seeing this.  I just set up a vagrant jessie box
with jessie-updates and security updates, and an "apt get install
guile-2.0-dev" worked fine.

I started the test system like this:

  mkdir tmp-test-guile-install
  cd tmp-test-guile-install
  vagrant init debian/jessie64
  vagrant up
  vagrant ssh
  sudo su -

and then adjusted the /etc/apt/sources.list to read:

  deb http://httpredir.debian.org/debian jessie main
  deb http://httpredir.debian.org/debian jessie-updates main
  deb http://security.debian.org/ jessie/updates main

and I had no /etc/apt/preferences.  After that:

  apt update
  apt install guile-2.0-dev

worked fine.

Perhaps that config isn't similar enough to yours?

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

Bug#850157: Please deprecate all ad-hoc patch systems

[Russ Allbery]

Ian Jackson  writes:

> The policy section "Source package handling: debian/README.source"
> should be entirely replaced with a requirement that

>   Running dpkg-source -x on a source package MUST produce the source
>   of the package, ready for editing, and allow one to make changes,
>   and run dpkg-buildpackage to produce a modified package, without
>   taking any additional steps.

>   If the upstream or Debian source code maintenance practices applying
>   to the package are nontrivial (for example, if the uploaded source
>   package is itself generated from a metarepository), this should be
>   documented in debian/README.source.

> And one could probably add

>   Previously, packages which had ad-hoc patch systems would document
>   their source code management practices in debian/README.source.
>   Source packages now MUST NOT use in-source-package patch systems
>   other than `3.0 (quilt)'.

How many packages in the archive would we make buggy by adding this
requirement?  I think it's probably the right thing to do anyway, but I'd
like to understand the scope of the disruption.

-- 
Russ Allbery (r...@debian.org)   

Bug#850204: java-gnome: FTBFS randomly (Fatal IO error 0 (Success) on X server)

[Santiago Vila]

Package: src:java-gnome
Version: 4.1.3-4
Severity: important

Dear maintainer:

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


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."
touch debian/stamp-autotools-files
chmod a+x /<>/./configure
mkdir -p .
cd . && CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" CXXFLAGS="-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" 
LDFLAGS="-Wl,-z,relro" /<>/./configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir="\${prefix}/include" --mandir="\${prefix}/share/man" 
--infodir="\${prefix}/share/info" --sysconfdir=/etc --localstatedir=/var 
--libexecdir="\${prefix}/lib/java-gnome" --srcdir=. --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib/jni 
jdk=/usr/lib/jvm/default-java

equivalence, v0.2
...configuring Java projects to build and run on Linux & Unix

Identify operating system: Debian


[... snipped ...]

SNAPdoc/api/org/gnome/gtk/RadioButton.png
SNAPdoc/api/org/gnome/gtk/ComboBox.png
SNAPdoc/api/org/gnome/gtk/Arrow.png
SNAPdoc/api/org/gnome/gtk/Notebook.png
SNAPdoc/api/org/gnome/gtk/Calendar.png
SNAPdoc/api/org/gnome/gtk/ComboBoxText.png
SNAPdoc/api/org/gnome/gtk/ComboBoxText--Entry.png
SNAPdoc/api/org/freedesktop/cairo/Context-line.png
SNAPdoc/api/org/gnome/gtk/TextView.png
SNAPdoc/api/org/gnome/gtk/TextView-BorderWindows.png
SNAPdoc/api/org/freedesktop/cairo/Context-arc.png
SNAPdoc/api/org/freedesktop/cairo/Context-arcNegative.png
SNAPdoc/api/org/freedesktop/cairo/Matrix-rotate.png
SNAPdoc/api/org/freedesktop/cairo/Matrix-scale.png
SNAPdoc/api/org/freedesktop/cairo/Matrix-translate.png
SNAPdoc/api/org/freedesktop/cairo/Context-rectangle.png
SNAPdoc/api/org/gnome/gtk/EntryCompletion.png
SNAPdoc/api/org/gnome/gtk/Entry.png
SNAPdoc/api/org/gnome/gtk/LinkButton.png
SNAPdoc/api/org/gnome/gtk/InfoBar.png
SNAPdoc/api/org/gnome/gtk/Switch.png
WRITE   doc/api/org/freedesktop/cairo/Operator-in.png
WRITE   doc/api/org/freedesktop/cairo/Operator-clear.png
WRITE   doc/api/org/freedesktop/cairo/Operator-source.png
WRITE   doc/api/org/freedesktop/cairo/Operator-over.png
WRITE   doc/api/org/freedesktop/cairo/Operator-out.png
WRITE   doc/api/org/freedesktop/cairo/Operator-atop.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_over.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_in.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_out.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_atop.png
WRITE   doc/api/org/freedesktop/cairo/Operator-xor.png
WRITE   doc/api/org/freedesktop/cairo/Operator-add.png
WRITE   doc/api/org/freedesktop/cairo/Operator-saturate.png
KILLXvfb

(.:12544): Gdk-WARNING **: .: Fatal IO error 0 (Success) on X server :99.

Makefile:87: recipe for target 'doc' failed
make[1]: *** [doc] Error 1
make[1]: Leaving directory '/<>'
/usr/share/cdbs/1/class/makefile.mk:77: recipe for target 
'debian/stamp-makefile-build' failed
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/java-gnome/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).


Note 1: It seems that the build is creating snapshots for the documentation,
and there is another bug (#836100) requesting a slightly different way to
take snapshots. Would fixing #836100 help to fix this one?

(X-Debbugs-Cc for Simon in case he knows the answer).

Note 2: The failure rate is very small, I have not tried to measure it.
I guess it is well below 10%, so if you try to reproduce it, please
try really really a *lot* of times.

Note 3: I would not really recommend trying a lot of times to reproduce it.
Instead, it could be more productive to look at the build logs and
try to guess *how* it may happen, but I don't really know the internals
of this package, so this is really up to you.

Thanks.

Bug#849586: reportbug incorrectly short-circuits From address escaping with non-ASCII characters

[Sandro Tosi]

control: forcemerge 848692 -1


On Wed, Dec 28, 2016 at 5:53 PM, Russ Allbery  wrote:
>
> if re.match(r'[\w\s]+$', realname):
> return '%s <%s>' % (realname, email)
>
> addr = email.utils.formataddr((realname, email))
>
> I suspect this worked fine in Python 2, since this regex doesn't use
> the UNICODE flag.  However, in Python 3, I believe regexes are str
> types by default and therefore Unicode by default, so this will match
> non-ASCII characters, short-circuit this logic, and never call
> formataddr.
>
> I'm not sure the original motivation for the short-circuit here, but
> I suspect just removing the re.match conditional and unconditionally
> calling email.utils.formataddr will produce the correct behavior.

i just did exactly that as part of 848692 (hence the merge)


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

Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress

[Brian May]

Ondrej Novy  writes:

> Maybe orphan it first?

Is this package used in Debian?

I tried to fix this issue, but the package has a FTBFS error:

ImportError: The ``fake-factory`` package is now called ``Faker``.

So I updated it to the latest version of python-factory-boy from Pypi
(referenced from debian/watch) but now it appears that this version is
missing the tests.

I guess I probably need to get the github sources instead of the Pypi
sources.

Not sure if I can git push to the openstack git repository, so I haven't
done so (and I might have to redo it anyway). If I can get this working,
I might move it to DPMT.
-- 
Brian May 

Bug#848692: reportbug fails with punctuation in name

[Sandro Tosi]

On Wed, Dec 21, 2016 at 9:24 PM, brian m. carlson
 wrote:
> The issue is this code:
>
> if re.match(r'[\w\s]+
> , realname):
> return '%s <%s>' % (realname, email)
>
> addr = email.utils.formataddr((realname, email))
>
> We don't take the branch since “.” (and “'”, etc.) are not in [\w\s],
> and then we throw an exception as email is not the module imported at
> the top, but the local variable.


I just removed that first if, as email.utils.formataddr() is more than
able to deal with all the special cases, we dont need to do that too,
thx!

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

Bug#848692: [Reportbug-maint] Bug#848692: reportbug fails with punctuation in name

[Sandro Tosi]

> A possible patch is to rename 'email' to 'emailaddr' in get_user_id, see
> attached patch.

Thanks Didier, i'm going to apply your patch soon!

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

Bug#849649: Pending fixes for bugs in the commons-daemon package

[pkg-java-maintainers]

tag 849649 + pending
thanks

Some bugs in the commons-daemon package are closed in revision
ccb7f63f4fb6388f671e8d4a354095319b698247 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/commons-daemon.git/commit/?id=ccb7f63

Commit message:

Fix build failure on arm architectures by appending the ${jvm_includes}

variable to CPPFLAGS.

Closes: #849649

Bug#845499: Clarification...

[Alec Leamas]

On Mon, 26 Dec 2016 17:38:47 +0100 Samuel Thibault 
 wrote:

> Hello,
>
> Mails sent to n...@bugs.debian.org are NOT sent to the submitter, so I
> actually never got this answer...

Oops, debian still has a few surprises in her sleeves... thanks for 
heads-up!


>
> Alec Leamas, on Fri 09 Dec 2016 15:13:12 +0100, wrote:
> > However, I would be happy to accept patches to make it build also on
> > hurd
>
> Here is the part of the originally submitted patch which is still
> needed.

Thanks. This is actually messier than it should be. A bad mentors build 
host + some misunderstandings between me and Gianfranco boiled down to 
that although the changelog in the -6  release mentions your patch it 
was actually not included.


Anyway, a new -7 update is already under way, this time With Patch 
Included (tm)


> > (atltough without USB and major desktop support, the hurd usecase
> > seems, well, far fetched).
>
> It's mostly meant to make reverse build-depends build, without having to
> explicitly drop lirc support.

Makes sense. And for me as upstream I have the overall feeling that 
compiling on other architectures sometimes reveals otherwise unnoticed 
bugs. So, thanks for your input.


I have also patched upstream according to 
https://paste.fedoraproject.org/520046/83574167, more or less your 
patch. Actually, it is your patch, it's your name on it :)


Cheers!

--alec

Bug#850203: scidavis: Upgrade to v.1.14

[Vladimir]

Package: scidavis
Version: 1.14-local1
Severity: normal
Tags: patch

Dear Maintainer,

  I prepared the files necessary to build the DEB package for SciDaVis
v.1.14 (the latest so far) and suggest them for your consideration.

  I downloaded the 'debian' catalog for SciDaVis version 1.D9-2 from
here: https://tracker.debian.org/pkg/scidavis and then made the
following changes:

1. Refreshed the 'changelog' file
2. Switched from compatibility level 7 to 9 in the 'compat' file
3. Replaced the 'libgsl-dev' with 'libgsl0-dev' in the 'control' file
4. Added the installation of the icons and desktop files in the
'install' file
5. Refreshed the 'qwtplot3d-headers.patch' file
6. Added the 'remove-unnecessary-doc-files.patch' to fix the
corresponding lintian warning about unneeded files (duplicates)
7. Added the 'scidavis-desktop-mime.patch' to fix the lintian warning
about the Exec string
8. Added the 'icon' tag to the 'scidavis.xml' file with MIME type description
9. Turned off the 'gcc6.patch' in 'patches/serial', since the upstream
sources are fixed already
10. Refreshed the 'without-3rdparty-liborigin.patch' for new source
files
11. Fixed the 'rules' file to use the native 'qmake_qt4' build system
with the necessary hardening (also fixes a number of lintial warnings).

A complete list of Lintian warnings I tried to fix is here:
https://lintian.debian.org/maintainer/georg...@debian.org.html#scidavis

After all these changes I managed to build the scidavis_1.14 package on
my Jessie AMD64 system successfully. So I hope my files may be used to
put the SciDaVis into Debian repository.

Here are the corresponding links:
https://ftp.wombat.org.ua/Debian/scidavis_1.14-local1.debian.tar.bz2
https://ftp.wombat.org.ua/Debian/scidavis_1.14-local1.debdiff

Regards,
   Vladimir




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

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

Versions of packages scidavis depends on:
ii  libc6 2.19-18+deb8u6
ii  libgcc1   1:4.9.2-10
ii  libgl1-mesa-glx [libgl1]  12.0.4-2~bpo8+1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgsl0ldbl   1.16+dfsg-2
ii  libmuparser2  2.2.3-4
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-qt3support 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-svg4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqwt5-qt4   5.2.3-1
ii  libqwtplot3d-qt4-00.2.7+svn191-7
ii  libstdc++64.9.2-10
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages scidavis recommends:
pn  qt-assistant-compat  

scidavis suggests no packages.

-- no debconf information

Bug#850202: dash: test with multiple conditions cannot handle variable whose expanded value is same as an operator

[J G Miller]

Package: dash
Version: 0.5.7-4+b1
Severity: normal

In Bourne shell script with dash, using either [ ] or test,

   test -n "${variable}" && echo "variable is set to -->${variable}<--"

works as expected even if the value of variable is to a value the same
as a test operator eg -ne or -nt

   variable="-ne" ; test -n "${variable}" && echo "variable is set to 
-->${variable}<--"
   variable is set to -->-ne<--

However the addition of another test condition with -a or -o results in an
unexpected behavior in that the expanded variable is now treated as an operator
and not just as the string as should be the case.

variable="-ne" ; test -n "${variable}" -a -n "${DISPLAY}" && echo "variable 
is set to -->${variable}<--"
dash: 1: test: Illegal number: -n

Applying quoted parentheses makes no difference.

variable="-ne" ; test \( -n "${variable}" \) -a \( -n "${DISPLAY}" \) && 
echo "variable is set to -->${variable}<--"
dash: 2: test: Illegal number: -n

Similarly bad behavior is seen with a variable set to "-nt", which is how I 
stumbled upon this problem.

variable="-nt" ; test \( -n "${variable}" \) -a \( -n "${DISPLAY}" \) && 
echo "variable is set to -->${variable}<--"
dash: 3: test: closing paren expected

So if the test is consists of a single condtion, the expanded variable does not 
cause
problems with the test, and should not affect the test if it is part of a 
multiple condition test.

Incidentally bash also has this problem.

So the short term kludge in a shell script is to do

 if [ -n "${variable_with_problem_value}" ]
 then
  if [ \( other_condition1 \) -a \( other_condition2 \) ]
  then
   ...



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii  debianutils  4.4+b1
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u6

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#850201: tendermint-go-flowrate: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:tendermint-go-flowrate
Version: 0.0~git20161104.0.a20c98e-1
Severity: important

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/tendermint/go-flowrate/flowrate
github.com/tendermint/go-flowrate/flowrate
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/tendermint/go-flowrate/flowrate
=== RUN   TestReader
--- PASS: TestReader (0.45s)
=== RUN   TestWriter
--- FAIL: TestWriter (0.51s)
io_test.go:140: w.Status(0) expected {true 2017-01-02 20:57:40.72 + 
UTC 400ms 0s 80 4 200 200 200 200 20 100ms 80.000%}; got {true 2017-01-02 
20:57:40.72 + UTC 420ms 0s 80 4 200 197 190 200 20 100ms 80.000%}
io_test.go:140: w.Status(1) expected {true 2017-01-02 20:57:40.72 + 
UTC 500ms 100ms 100 5 200 200 200 200 0 0s 100.000%}; got {true 2017-01-02 
20:57:40.72 + UTC 520ms 100ms 100 5 200 197 192 200 0 0s 100.000%}
FAIL
exit status 1
FAILgithub.com/tendermint/go-flowrate/flowrate  0.962s
dh_auto_test: go test -v -p 1 github.com/tendermint/go-flowrate/flowrate 
returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/tendermint-go-flowrate/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 10%.

Thanks.

Bug#850198: golang-github-dvsekhvalnov-jose2go: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-dvsekhvalnov-jose2go
Version: 1.2-1
Severity: important

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/dvsekhvalnov/jose2go 
github.com/dvsekhvalnov/jose2go/aes github.com/dvsekhvalnov/jose2go/arrays 
github.com/dvsekhvalnov/jose2go/base64url 
github.com/dvsekhvalnov/jose2go/compact github.com/dvsekhvalnov/jose2go/kdf 
github.com/dvsekhvalnov/jose2go/keys/ecc 
github.com/dvsekhvalnov/jose2go/keys/rsa github.com/dvsekhvalnov/jose2go/padding
github.com/dvsekhvalnov/jose2go/base64url
github.com/dvsekhvalnov/jose2go/arrays
github.com/dvsekhvalnov/jose2go/aes
github.com/dvsekhvalnov/jose2go/compact
github.com/dvsekhvalnov/jose2go/kdf
github.com/dvsekhvalnov/jose2go/keys/ecc

[... snipped ...]

--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/aes 0.004s
=== RUN   Test
OK: 6 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/arrays  0.003s
=== RUN   Test
err = illegal base64 data at input byte 32
OK: 3 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/base64url   0.003s
=== RUN   Test

err=illegal base64 data at input byte 4
OK: 8 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/compact 0.003s
=== RUN   Test
OK: 16 passed
--- PASS: Test (0.15s)
PASS
ok  github.com/dvsekhvalnov/jose2go/kdf 0.151s
=== RUN   Test
OK: 6 passed
--- PASS: Test (0.04s)
PASS
ok  github.com/dvsekhvalnov/jose2go/keys/ecc0.040s
=== RUN   Test
OK: 4 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/keys/rsa0.005s
=== RUN   Test
OK: 13 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/padding 0.003s
dh_auto_test: go test -v -p 1 github.com/dvsekhvalnov/jose2go 
github.com/dvsekhvalnov/jose2go/aes github.com/dvsekhvalnov/jose2go/arrays 
github.com/dvsekhvalnov/jose2go/base64url 
github.com/dvsekhvalnov/jose2go/compact github.com/dvsekhvalnov/jose2go/kdf 
github.com/dvsekhvalnov/jose2go/keys/ecc 
github.com/dvsekhvalnov/jose2go/keys/rsa 
github.com/dvsekhvalnov/jose2go/padding returned exit code 1
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-dvsekhvalnov-jose2go/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 6%.

Thanks.

Bug#850200: golang-github-google-gofuzz: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-google-gofuzz
Version: 0.0~git20150903.0.e4af62d-2
Severity: important

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/google/gofuzz
github.com/google/gofuzz
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/google/gofuzz
=== RUN   TestFuzz_basic
--- PASS: TestFuzz_basic (0.00s)
=== RUN   TestFuzz_structptr
--- FAIL: TestFuzz_structptr (0.00s)
fuzz_test.go:96: a not nil seems to not be getting set, was zero value 
10 times
fuzz_test.go:96: as seems to not be getting set, was zero value 10 times
=== RUN   TestFuzz_structmap
--- PASS: TestFuzz_structmap (0.00s)
=== RUN   TestFuzz_structslice
--- PASS: TestFuzz_structslice (0.00s)
=== RUN   TestFuzz_custom
--- PASS: TestFuzz_custom (0.00s)
=== RUN   TestFuzz_interface
--- PASS: TestFuzz_interface (0.00s)
=== RUN   TestFuzz_interfaceAndFunc
--- PASS: TestFuzz_interfaceAndFunc (0.00s)
=== RUN   TestFuzz_noCustom
--- PASS: TestFuzz_noCustom (0.00s)
=== RUN   ExampleSimple
--- PASS: ExampleSimple (0.00s)
=== RUN   ExampleCustom
--- PASS: ExampleCustom (0.00s)
=== RUN   ExampleComplex
--- PASS: ExampleComplex (0.00s)
=== RUN   ExampleMap
--- PASS: ExampleMap (0.00s)
=== RUN   ExampleSingle
--- PASS: ExampleSingle (0.00s)
=== RUN   ExampleEnum
--- PASS: ExampleEnum (0.00s)
FAIL
exit status 1
FAILgithub.com/google/gofuzz0.008s
dh_auto_test: go test -v -p 1 github.com/google/gofuzz returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-google-gofuzz/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 6%.

Thanks.

Bug#850197: golang-github-dgryski-go-bits: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-dgryski-go-bits
Version: 0.0~git20151205.0.86c69b3-1
Severity: important

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/dgryski/go-bits
github.com/dgryski/go-bits
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/dgryski/go-bits
=== RUN   TestQuickCtz
--- PASS: TestQuickCtz (0.00s)
=== RUN   TestQuickClz

[... snipped ...]

/usr/lib/go-1.7/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc420044fa8 
sp=0xc420044fa0
created by testing.(*T).Run
/usr/lib/go-1.7/src/testing/testing.go:646 +0x2ec

goroutine 1 [chan receive]:
testing.(*T).Run(0xc420018180, 0x53cf14, 0xf, 0x54be38, 0xc42003fd01)
/usr/lib/go-1.7/src/testing/testing.go:647 +0x316
testing.RunTests.func1(0xc420018180)
/usr/lib/go-1.7/src/testing/testing.go:793 +0x6d
testing.tRunner(0xc420018180, 0xc42003fe20)
/usr/lib/go-1.7/src/testing/testing.go:610 +0x81
testing.RunTests(0x54be58, 0x5dd7c0, 0x3, 0x3, 0x53c471)
/usr/lib/go-1.7/src/testing/testing.go:799 +0x2f5
testing.(*M).Run(0xc42003fee8, 0xc42000e510)
/usr/lib/go-1.7/src/testing/testing.go:743 +0x85
main.main()
github.com/dgryski/go-bits/_test/_testmain.go:58 +0xc6

rax0x54be20
rbx0x38fc2ffac2fd9401
rcx0x54be50
rdx0x38fc2ffac2fd9401
rdi0xc4200449b8
rsi0x479100
rbp0xc420044998
rsp0xc420044970
r8 0x18b
r9 0xc42000ff48
r100x50e6a0
r110x0
r120x10
r130x1f50
r140x1f6
r150x582480
rip0x479105
rflags 0x10216
cs 0x33
fs 0x0
gs 0x0
exit status 2
FAILgithub.com/dgryski/go-bits  0.022s
dh_auto_test: go test -v -p 1 github.com/dgryski/go-bits returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-dgryski-go-bits/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 17%.

Thanks.

Bug#850199: golang-github-gogits-cron: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-gogits-cron
Version: 0.0~git20160810.32.7f3990a-1
Severity: important

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/gogits/cron
github.com/gogits/cron
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/gogits/cron
=== RUN   TestConstantDelayNext
--- PASS: TestConstantDelayNext (0.00s)
=== RUN   TestFuncPanicRecovery

[... snipped ...]

--- PASS: TestAddWhileRunning (1.00s)
=== RUN   TestAddWhileRunningWithDelay
--- PASS: TestAddWhileRunningWithDelay (6.01s)
=== RUN   TestSnapshotEntries
--- PASS: TestSnapshotEntries (1.99s)
=== RUN   TestMultipleEntries
--- PASS: TestMultipleEntries (1.00s)
=== RUN   TestRunningJobTwice
--- PASS: TestRunningJobTwice (2.00s)
=== RUN   TestRunningMultipleSchedules
--- PASS: TestRunningMultipleSchedules (1.00s)
=== RUN   TestLocalTimezone
2017/01/02 21:06:59 End of range (60) above maximum (59): 60
--- FAIL: TestLocalTimezone (1.01s)
=== RUN   TestStopWithoutStart
--- PASS: TestStopWithoutStart (0.00s)
=== RUN   TestJob
--- PASS: TestJob (0.99s)
=== RUN   TestRange
--- PASS: TestRange (0.00s)
=== RUN   TestField
--- PASS: TestField (0.00s)
=== RUN   TestBits
--- PASS: TestBits (0.00s)
=== RUN   TestSpecSchedule
--- PASS: TestSpecSchedule (0.00s)
=== RUN   TestActivation
--- PASS: TestActivation (0.00s)
=== RUN   TestNext
--- PASS: TestNext (0.00s)
=== RUN   TestErrors
2017/01/02 21:07:01 Expected 5 or 6 fields, found 1: xyz
2017/01/02 21:07:01 End of range (60) above maximum (59): 60
2017/01/02 21:07:01 End of range (60) above maximum (59): 60
2017/01/02 21:07:01 Failed to parse int from XYZ: strconv.ParseInt: parsing 
"XYZ": invalid syntax
--- PASS: TestErrors (0.00s)
=== RUN   TestNextWithTz
--- PASS: TestNextWithTz (0.00s)
FAIL
exit status 1
FAILgithub.com/gogits/cron  18.062s
dh_auto_test: go test -v -p 1 github.com/gogits/cron returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-gogits-cron/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 1.5%.

Thanks.

Bug#645828: your search.cpan.org/metacpan.org commit / Bug#645828: Fold libdatetime-astro-sunrise-perl into libdatetime-event-sunrise-perl

[gregor herrmann]

On Mon, 25 May 2015 19:48:10 +0200, Axel Beckert wrote:

> I also wonder if #645828 is fixed with libdatetime-event-sunrise-perl
> being in Debian or if #645828 is only fixed when
> libdatetime-astro-sunrise-perl has been removed from the archive.

There's more background information in Ubuntu's launchpad from
upstream:

https://bugs.launchpad.net/bugs/1654056

I guess we should just remove libdatetime-astro-sunrise-perl …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Die Quote: Kali Spera Mamatschi


signature.asc
Description: Digital Signature

Bug#849918: RFS: tinymux/2.10.1.13-1

[Tobias Frost]

Am Donnerstag, den 05.01.2017, 00:24 +0100 schrieb Tobias Frost:
> 
> I wrote you a rule file as starting point. Attached. It is thought to
> get you started. 
> (Some parts are missing, like the hardening; also stuff and you need
> to
> do outside of the rules, like to create the file d/clean with all
> files
> listed and d/install to to put the files actually in place
> 
PS: I needed to add --no-parallel because parallel build is broken
here. This is also bug in your Makefile...

To trigger
#debuild -j1
(works)

#debuild -j4
(...)
g++ -g -O2 -fdebug-prefix-
map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o stubslave stubslave.o -L.
-lm -lcrypt   -lmux 
/usr/bin/ld: cannot find -lmux
collect2: error: ld returned 1 exit status
Makefile:189: recipe for target 'stubslave' failed
make[1]: *** [stubslave] Error 1
make[1]: *** Waiting for unfinished jobs
( if [ -f netmux ]; then mv -f netmux netmux~ ; fi )
g++ -g -O2 -fdebug-prefix-
map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o netmux _build.o alarm.o
alloc.o attrcache.o boolexp.o bsd.o command.o comsys.o conf.o cque.o
create.o db.o db_rw.o eval.o file_c.o flags.o funceval.o funceval2.o
functions.o funmath.o game.o help.o htab.o local.o log.o look.o mail.o
match.o mathutil.o mguests.o modules.o move.o muxcli.o netcommon.o
object.o predicates.o player.o player_c.o plusemail.o powers.o quota.o
rob.o pcre.o set.o sha1.o speech.o stringutil.o strtod.o svdrand.o
svdhash.o timer.o timeabsolute.o timedelta.o timeparser.o timeutil.o
timezone.o unparse.o utf8tables.o vattr.o walkdb.o wild.o
wiz.o  version.o -L. -lm -lcrypt -lmux
/usr/bin/ld: cannot find -lmux
collect2: error: ld returned 1 exit status
Makefile:198: recipe for target 'netmux' failed
make[1]: *** [netmux] Error 1
make[1]: Leaving directory
'/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13/src'

Bug#849918: RFS: tinymux/2.10.1.13-1

[Tobias Frost]

Am Mittwoch, den 04.01.2017, 13:06 -0700 schrieb Stephen Dennis:
> I've never been able to get the watch file to work right, and it is
> mis-behaving like it always has. 

Admitted watchfiles are not easy :) And your directory layout makes it
even more difficult...
However, you can use this as starting point:

version=4
ftp://ftp.tinymux.org/tinymux-2.10/([\d\.]+)/mux-@ANY_VERSION@.unix@ARC
HIVE_EXT@

Though this will not the alpha version as this'd canonically be the
newest version. 

(please add signature checking yourself)

> I think I've made all the other changes
> requested except I'm still a total loss as to how to migrate to the
> short
> debhelper format.

I wrote you a rule file as starting point. Attached. It is thought to
get you started. 
(Some parts are missing, like the hardening; also stuff and you need to
do outside of the rules, like to create the file d/clean with all files
listed and d/install to to put the files actually in place

Recommended readings:
- https://www.debian.org/doc/manuals/maint-guide -- especially the §5:
5.11 and 5.5 (in other words: d/dirs is probably not needed)
- dh_clean(1)

> On Tue, Jan 3, 2017 at 7:28 AM, Tobias Frost  wrote:
> 
> > > Very much appreciate the feedback. Willing to learn, but
> > > overwhelmed by
> > 
> > the
> > > Debian machinery.
> > 
> > You're welcome!
> > 
> > Yes, indeed it can be overwhelming. But don't worry, we've all had
> > to learn
> > this ;-)
> > 
> > > Stupid question at the top: If I dput another package, does it
> > > update
> > 
> > this
> > > one or do I need to delete the currently uploaded package from
> > > mentors
> > > first?
> > 
> > You can just dput it. It will overwrite the previous version.
> > 
> > > - d/changelog. A lot has changed. Here are pointers to 'brief'
> > > change
> > 
> > logs
> > > for 2.7, 2.9, and 2.10:
> > > 
> > > http://www.tinymux.org/changes27.txt
> > > http://www.tinymux.org/changes29.txt
> > > http://www.tinymux.org/changes.txt
> > > 
> > > That's four years of why to retrace, and the actual check-in
> > > messages
> > 
> > from
> > > the repository would be much longer. Does Debian really want all
> > > of that?
> > 
> > No, the debian changelog is only for changes done to the (Debian)
> > packaging,
> > not to the upstream source. See the Debian Policy §4.4
> > You ship already an upstream changelog (though it seems only to be
> > limited
> > to
> > the last version and more a NEWS file than a real changelog...)
> > 
> > > - d/patches
> > > 
> > >   - Not sure what a dep3 header is, yet. More to learn.
> > 
> > http://dep.debian.net/deps/dep3/
> > Hint: $ quilt header -e --dep3
> > 
> > >   - All but one of the patches is checked-in upstream already.
> > 
> > Ok. (Document that with the appropiate dep3-header "Applied-
> > Upstream")
> > 
> > >   - I don't know how to have config.guess be updated at build
> > > time? Did
> > 
> > not
> > > know about that one. Is this part of automake? TinyMUX is more
> > > autoconf
> > > than it once was, but it still doesn't use automake or libtool.
> > 
> > https://wiki.debian.org/Autoreconf
> > 
> > NOTE: When you change to compat level 10 and short debhelper format
> > it is
> > even
> > more easier, as compat level 10 default to use dh_autoreconf.
> > 
> > >   - Dependency-created-noise.patch. The way users normally build
> > 
> > TinyMUX is
> > > untar the package, ./configure;make depend;make. The 'make
> > > depend' scans
> > > all the include files and builds ".depend" which is then re-
> > > consumed by
> > > Makefile. It must exist -- at least empty. The Debian build
> > > system would
> > > see either way as a source change, but it isn't a change to taken
> > 
> > upstream.
> > > It always changes in different ways in every environment.
> > 
> > Another reason to get rid of it to make it really portable ;-) But
> > as said,
> > patching it is wrong, especially if it can be reconstructed during
> > the
> > build.
> > 
> > If it just needs to exists, why not
> > - remove it e.g via (the file) debian/clean
> > - after configure, touch it to be present
> > - in build run make
> > 
> > > - d/copyright dep5...OK, more to study. The copyright is the same
> > > as
> > > previous 2.6 package except for the dates. That was hammered out
> > > between
> > > the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and
> > > RhostMUSH). I'm
> > > loath to change the substance of it, but if there is some Debian-
> > > friendly
> > > form to call out that it is the Artistic license, that seems
> > > reasonable
> > > enough.
> > 
> > Well that happens when a package gets some care only after several
> > years
> > (btw, THANK YOU for this caring!) Policies / Procedures have been
> > updated,
> > so the "Machine-readable debian/copyright file" is now standard.
> > 
> > > - silent rule. TinyMUX uses the other autoconf tools, but not
> > > libool or
> > > automake. Silent rule seems to be a term from those things?
> > 
> > When I compiled the package I 

Bug#7330: Greeting ! I Am Mrs Monat Adama From Aleppo- Syria

[info...@bigpond.com]

Greeting !
How are you? My name is Mrs Monat Adama, a Citizen of Syria lived
in Aleppo- Syria., I'm one of the former senior inspector for Syria
National Petroleum Company(Kawkab Oil Company). I have Business
investment transaction worth $8.2 Million.  I will like to relocate
out from Syria, Because here in Syria is serious war here. I wait to
hear from you as soon as you see this message
regards,
Mrs Monat Adama

Bug#519590: Greeting ! I Am Mrs Monat Adama From Aleppo- Syria

[info...@bigpond.com]

Greeting !
How are you? My name is Mrs Monat Adama, a Citizen of Syria lived
in Aleppo- Syria., I'm one of the former senior inspector for Syria
National Petroleum Company(Kawkab Oil Company). I have Business
investment transaction worth $8.2 Million.  I will like to relocate
out from Syria, Because here in Syria is serious war here. I wait to
hear from you as soon as you see this message
regards,
Mrs Monat Adama

Bug#850060: 2.0.874-2~exp1 issues

[Christian Seiler]

Control: reopen -1

Hi,
(reopening the bug report since iscsiuio doesn't actually work
according to what you're telling me)

On 01/04/2017 11:30 PM, Andrew Patterson wrote:
> 1. In debian/extra/initramfs.local-top and
> debian/extra/initramfs.local-bottom /sbin/iscsuio creates a pid file
> in /run/iscsiuio.pid. You cannot override it on the command-line. The
> --pidfile option for start-stop-daemon should point to this location
> instead of /run/initramfs/iscsiuio.pid.

Gah. I thought I had fixed that before the upload. :-(
A good thing there's experimental...

OTOH, initramfs should write to /run/initramfs only, so maybe
we should pass -p /run/initramfs/iscsiuio.pid to iscsiuio
instead as well.

> 2. The /sbin/iscsiuio deamon is trying to create a logfile in
> /var/log/iscsiuio.log. The /var/log directory does not exist in the
> initramfs.

Unfortunately that's hardcoded. OTOH from reading the code
this shouldn't be an issue.

> 3. The iscsiuio daemon is dieing before or during iscsistart -b. I am
> investigating why. It works fine when run after boot.

This is weird, on my test VM (no offloading NIC though) it
does start (and shut down again).

Question: does the network card require firmware for offloading
to work? If that's the case we might need to add the firmware
to the initramfs or this to work properly...

> 4. The commit 02c3051 "Don't ignore offloading NICs in iscsistart"
> will cause the interface to be configured in both iscsistart -N and in
> iscsistart -b for cards with iscsi hardware offload. I suspect we
> instead need a flag in iscsistart to bring up the NIC in iscsistart
> regardless if the NIC uses an offloadable driver. The local-top script
> can use this flag if /sbin/iscsiuio is not present, e.g.,
> 
> ISCSISTART_FLAGS=""
> if [ ! -x /sbin/iscsiuio ] ; then
>ISCSISTART_FLAGS="-S"
> fi

Hmm, now I see what you mean. I also dug up this commit which
gives a little insight.

https://github.com/open-iscsi/open-iscsi/commit/ee115be828362653478e6fe7cd4c6ee3318223ff

However, I think the solution is different from what you suggest: the
"fix" for #850057 is wrong I believe.

Debian sid package (w/o -DOFFLOAD_BOOT_SUPPORTED):

 - cxgb*i: iscsistart -N ignores interface
   iscsistart -b doesn't configure offloading
   => won't work

 - bnx2i (any mode): iscsistart -N ignores interface
 iscsistart -b doesn't configure offloading
   => won't work

Current upstream situation (w/ -DOFFLOAD_BOOT_SUPPORTED):

 - cxgb*i: iscsistart -N ignores interface
   iscsistart -b configures offloading 
   => should work
  (but don't have hardware)
  (also: remind me to check whether we copy the
  module into the initramfs)

 - bnx2i non-hba: iscsistart -N ignores it
  iscsistart -b doesn't configure offloading
   => won't work

 - bnx2i hba: iscsistart -N ignores it
  iscsistart -b configures offloading
   => should work (once iscsiuio is running)

"Fix" for 850057 (in experimental):

 - cxgb*i: iscsistart -N configures interface on host
   iscsistart -b configures offloading
 => no idea what happens thereafter
(since MAC address is the same on these cards: is
this a problem if they have the same IP?)

 - bnx2i non-hba: iscsistart -N configures interface
  iscsistart -b doesn't configure offloading,
but enables software iSCSI
  => should work

 - bnx2i hba: iscsistart -N configures interface
  iscsistart -b configures offloading
  => same IP, different MAC addresses
  => will cause trouble

The ideal solution would be to mirror the check that is done
for -b in -N. In that case we'd either configure the host
interface (and use software iSCSI), or configure offloading
(and use hardware iSCSI), but never both, and never neither.
So instead of the current patch for #850057 I would suggest
to do that instead. That should then also be upstream-able. I
can prepare a patch for that tomorrow.

That still leaves us with the question why iscsiuio doesn't
appear to work in the initramfs on your system. You could
just add strace to your initramfs and call iscsiuio in a
detached strace, a la

old:
start-stop-daemon ... /sbin/iscsiuio

new:
start-stop-daemon ... /bin/strace -- -D -f \
   -o /run/initramfs/iscsiuio.trace  -- /sbin/iscsiuio

(The first -- is for start-stop-daemon, the second one for
strace itself.)

Regards,
Christian

Bug#850070: Processed: reassign 850070 to pylint

[Sandro Tosi]

I'm not convinced we should change anything in pylint to support
emacs21, which has been removed from debian since 2009

On Wed, Jan 4, 2017 at 9:21 AM, Debian Bug Tracking System
 wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> reassign 850070 pylint 1.5.6-1
> Bug #850070 [pyli] pyli: Fail to install if emacs21 is installed.
> Warning: Unknown package 'pyli'
> Bug reassigned from package 'pyli' to 'pylint'.
> Ignoring request to alter found versions of bug #850070 to the same values 
> previously set
> Ignoring request to alter fixed versions of bug #850070 to the same values 
> previously set
> Bug #850070 [pylint] pyli: Fail to install if emacs21 is installed.
> Marked as found in versions pylint/1.5.6-1.
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
> --
> 850070: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850070
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



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

Bug#850196: unblock: dgit/2.14

[Ian Jackson]

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

Please unblock package dgit

dgit 2.13 has a HIDEOUS bug which causes it to generate malformed git
commits.  (#849041) To my surprise, extreme disappointment, and soon
everyone's annoyance, nothing in git (not even the usual git server
code) detected this.

Everyone who is using dgit 2.x must upgrade to 2.14 immediately.

The changes from 2.13 to 2.14 are:

 * The changelog.

 * The fixes for the two occurrences of this bug.

 * Changes to the test suite which I think will avoid any further
   bugs of this kind.

The test suite changes are textually large and hard to review, but:
This is a DEP-8 test suite and it is not run during build, so it
cannot cause a FTBFS bug.  Furthermore, I have (of course) run it:
both in its ad-hoc mode on stretch and done a formal full-on adt-run
in a sid schroot.  It passes (provided I work around the existing bug
#840673 in dput).

I will attach the output of
  debdiff dgit_2.{13,14}.dsc >dgit_2.13-2.14.debdiff
  debdiff --exclude=test dgit_2.{13,14}.dsc >dgit_2.13-2.14.exclude-test.debdiff

Under the circumstances I hope you agree I have chosen the right
severity for this bug.

unblock dgit/2.14

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru dgit-2.13/debian/changelog dgit-2.14/debian/changelog
--- dgit-2.13/debian/changelog	2016-12-21 01:32:41.0 +
+++ dgit-2.14/debian/changelog	2017-01-04 22:52:55.0 +
@@ -1,3 +1,14 @@
+dgit (2.14) unstable; urgency=critical
+
+  CRITICAL BUGFIX:
+  * Do not generate bogus commits with --overwrite or import-dsc.
+Closes:#849041.
+
+  Test suite:
+  * Run a lot of git-fsck.
+
+ -- Ian Jackson   Wed, 04 Jan 2017 22:52:55 +
+
 dgit (2.13) unstable; urgency=high
 
   Changed behaviour:
diff -Nru dgit-2.13/dgit dgit-2.14/dgit
--- dgit-2.13/dgit	2016-12-20 21:34:21.0 +
+++ dgit-2.14/dgit	2017-01-04 22:11:08.0 +
@@ -3538,7 +3538,7 @@
 parent $dgitview
 parent $archive_hash
 author $authline
-commiter $authline
+committer $authline
 
 $msg_msg
 
@@ -5944,10 +5944,14 @@
 	progress "Import, merging.";
 	my $tree = cmdoutput @git, qw(rev-parse), "$newhash:";
 	my $version = getfield $dsc, 'Version';
+	my $clogp = commit_getclogp $newhash;
+	my $authline = clogp_authline $clogp;
 	$newhash = make_commit_text <

Bug#738897: RM libsigc++-1.2

[Michael Biebl]

Control: tags -1 - moreinfo

On Mon, 26 Sep 2016 09:16:09 -0400 Scott Kitterman
 wrote:
> On Sunday, September 18, 2016 11:22:51 PM Adrian Bunk wrote:
> > Control: reassign 738897 ftp.debian.org
> > Control: retitle 738897 RM: libsigc++-1.2 -- RoQA; orphaned, obsolete
> > version Control: block 738897 by 672390
> > 
> > 
> > libsigc++-1.2 (last upstream release in 2005) is an old version
> > of libsigc++-2.0.
> > 
> > The only rdep left is freqtweak (marked as blocking this bug),
> > whose maintainer has promised to fix this issue soon.
> 
> This still needs fixing.  Please remove the moreinfo tag once that's done.

At this point it's probably safe to assume that freqtweak won't be fixed.

The package is orphaned [1] and dead upstream (last upstream activity is
over 7 years ago [2]).
Please remove it along with libsigc++-1.2.

Removing the moreinfo tag.

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846810
[2] https://sourceforge.net/projects/freqtweak/files/
-- 
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#850195: ITP: extinction -- Fast interstellar dust extinction laws

[Florian Rothmaier]

Package: wnpp
Severity: wishlist

* Package name: Extinction
  Version : 0.3.0
  Upstream Author : Kyle Barbary 
* URL : https://github.com/kbarbary/extinction
* License : MIT
  Programming Lang: Python/Cython
  Description : Fast interstellar dust extinction laws

Extinction provides a library with Cython-optimised implementations of
empirical dust extinction laws found in the astronomical literature.

This library is a dependency of the sncosmo software. Hence packaging
Extinction is a prerequisite of packaging sncosmo.

It will be maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [1].

Best regards,

Florian

[1] https://anonscm.debian.org/cgit/debian-astro/packages/extinction.git

Bug#849041: dgit: psuedomerge commits have no author.

[Ian Jackson]

peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):
> I have a script that can be used to fix the commits but of course the only 
> way to fix them is to change history and that has obvious downsides.

Thanks.  I'm going to write a better script.  I think the
history-rewriting is inevitable :-(.

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#849845: got hit as well

[shirish शिरीष]

Hi all,
Got hit on one of my machines which upgraded before the serious bug
was invoked -

└─[$] apt-cache policy gnupg dirmngr

gnupg:
  Installed: 2.1.17-2
  Candidate: 2.1.17-2
  Version table:
 *** 2.1.17-2 600
600 http://httpredir.debian.org/debian stretch/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
dirmngr:
  Installed: 2.1.17-2
  Candidate: 2.1.17-2
  Version table:
 *** 2.1.17-2 600
600 http://httpredir.debian.org/debian stretch/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


─[$] gpg --keyserver pgp.mit.edu --recv-keys DAD95197

gpg: keyserver receive failed: No keyserver available

Tried multiple times and failed :(

Look forward to getting it fixed.

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

Bug#850141: ITP: node-jsbn -- The jsbn library is a fast, portable implementation of large-number math in pure JavaScript, enabling public-key crypto and other applications on desktop and mobile brows

[Philip Hands]

abhi.kuvale...@yahoo.com writes:

> Package: jsbn
> Severity: wishlist
> Owner: Abhishek Kuvalekar 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name    : node-jsbn
>   Version : 0.1.0

The github version claims to currently be 1.0.0 -- is this just a typo,
or are you packaging an old version on purpose for some reason?

>   Upstream Author : Tom Wu
> * URL : https://github.com/andyperlitch/jsbn
> * License : BSD
>   Programming Lang: JavaScript
>   Description : The jsbn library is a fast, portable implementation of 
> large-number math in pure JavaScript, enabling public-key crypto an$

The short description is too long, and is truncated.

The long decription is missing.

There should at least be an indication that this relates to node.js, and
what that might mean (for people that are not already aware of node.js)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#849020: jessie-pu: package systemd/215-17+deb8u6

[Cyril Brulebois]

Adam D. Barratt  (2017-01-04):
> Control: tags -1 + moreinfo
> 
> On Wed, 2016-12-21 at 22:07 +0100, Michael Biebl wrote:
> > I'd like to make a stable upload for systemd with the following changes.
> > All the changes are cherry-picks/backports from fixes which have already
> > been applied to systemd in unstable.
> > 
> > The full debdiff is attached. For better readability I will provide an
> > annotated debian/changelog which links to the invidual commits
> 
> I think this looks okay (although ordering changes always make me a
> little paranoid), and while it doesn't look like any of the changes
> should affect the udebs or d-i, I'd still appreciate a kibi-ack.

Looks good to me indeed.


KiBi.


signature.asc
Description: Digital signature

Bug#850126: ITP: node-aproba -- A rediculously light-weight argument validator

[Philip Hands]

Tushar Agey  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Tushar Agey 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-aproba
>   Version : 1.0.4
>   Upstream Author : Rebecca Turner 
> * URL : https://github.com/iarna/aproba
> * License : ISC
>   Programming Lang: JavaScript
>   Description : A rediculously light-weight argument validator
>

That should be spelt 'ridiculously'

Also, where is the long description?  There should at the very least be
some indication that these node-* packages are related to node.js, and
what that might be (for people that don't already know).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#850194: evolution cant's start (dist jessie armhf)

[Winfried Kybelka]

Package: evolution
Version: 3.12.9~git20141130.241663-1+b1
Severity: normal
Tags: d-i

Dear Maintainer,

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

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

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



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.39+ (SMP w/8 CPU cores; PREEMPT)
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 evolution depends on:
ii  dbus   1.8.20-0+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  evolution-common   3.12.9~git20141130.241663-1
ii  evolution-data-server  3.12.9~git20141128.5242b0-2+deb8u2
ii  gnome-icon-theme   3.12.0-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u6
ii  libcamel-1.2-493.12.9~git20141128.5242b0-2+deb8u2
ii  libclutter-gtk-1.0-0   1.6.0-1
ii  libecal-1.2-16 3.12.9~git20141128.5242b0-2+deb8u2
ii  libedataserver-1.2-18  3.12.9~git20141128.5242b0-2+deb8u2
ii  libevolution   3.12.9~git20141130.241663-1+b1
ii  libglib2.0-0   2.42.1-1+b1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libical1a  1.0-1.3
ii  libnotify4 0.7.6-2
ii  libsoup2.4-1   2.48.0-1
ii  libwebkitgtk-3.0-0 2.4.9-1~deb8u1
ii  libxml22.9.1+dfsg1-5+deb8u4
ii  psmisc 22.21-2

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-3+deb8u1
ii  evolution-plugins  3.12.9~git20141130.241663-1+b1
ii  spamassassin   3.4.0-6
ii  yelp   3.14.1-1

Versions of packages evolution suggests:
ii  evolution-ews   3.12.9~git20141130.278fe7-1+b1
ii  evolution-plugins-experimental  3.12.9~git20141130.241663-1+b1
ii  gnupg   1.4.18-7+deb8u3
pn  network-manager 

-- debconf information:
  evolution/kill_processes:
  evolution/needs_shutdown:
winfried@jessie-A80:~$ evolution
libEGL warning: DRI2: failed to authenticate
Unable to eglMakeCurrent with no surface

Bug#849119: playonlinux: Buttons fail to appear in most or all pop up dialog boxes

[Bertrand Marc]

Dear Ray,

Thank you for taking the time to investigate. I forwarded the issue upstream, 
and hopefully they will come up with a solution soon enough.

In the meantime, I will downgrade the severity of this bug, as playonlinux is 
still usable by most people.

Best regards,
Bertrand

PS Could you please put the bug email address in copy?


Le 30/12/2016 à 19:45, Raymond F. Anthracite a écrit :
> Dear Bertrand,
> 
> Upon further investigation, I think I have a better idea where the problem 
> lies.
> 
> It appears to be an issue with the size of the window decoration at the top 
> in 
> pixels not being compensated for by the program.  It happens in all window 
> managers.  My computer is running through a 4k 55" television, and I run at 
> font sizes around 22 or so.  Bigger fonts make the window decoration title 
> bar 
> bigger, which displace the buttons at the bottom, and the window isn't 
> expandable so it doesn't make room for it.
> 
> I suspect you could reproduce the problem on a system with normal specs (not 
> a 
> 4k 55 inch TV) by using a really big titlebar font size, and restarting your 
> window manager (the window managers sometimes seem to pick a titlebar size on 
> startup and then not change much it even if you change the font size), and 
> then you will notice the buttons on the bottom start to get cut off.
> 
> The problem happens in a brand new gnome session for me with a new user, with 
> a new home directory, with the default font sizes, but instead of being 
> entirely cut off the buttons are only partially cut off, so the program is 
> still usable to a degree.  I believe that this is because the gnome titlebars 
> are smaller by default, not for any other reason.
> 
> It also seems to work somewhat in kde if i start up with normal font sizes 
> and 
> then make them bigger, as that makes the title bar less big than it does if I 
> start up with them big for some reason.  The buttons are still mostly cut off 
> but I can click them, barely.
> 
> I included a pic where they aren't entirely cut off, but just mostly cut off 
> so that you can see what is happening.   It's from a time when I started up 
> kde with small fonts, then increased the font size of the titlebar to make 
> the 
> problem more noticable.  Normally all my fonts are about as big as the one in 
> the titlebar.  It seems to depend only on the size of the titlebar.  I don't 
> think the font size matters except in so far as that causes the title bar 
> size 
> to change, which it often does.
> 
> Best wishes,
> 
> Ray
> 
> $ xrandr -q
> Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
> DVI-D-0 disconnected (normal left inverted right x axis y axis)
> HDMI-0 disconnected (normal left inverted right x axis y axis)
> HDMI-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y 
> axis) 1210mm x 680mm
>3840x2160 30.00 +  59.94*   50.0029.9725.0023.98  
>4096x2160 59.9450.0029.9725.0024.0023.98  
>1920x1080 60.0059.9450.0029.9725.0023.9760.00  
>   
> 50.04  
>1680x1050 59.95  
>1600x900  60.00  
>1440x900  59.89  
>1366x768  59.79  
>1280x1024 75.0260.02  
>1280x800  59.81  
>1280x720  60.0059.9450.00  
>1152x864  75.00  
>1024x768  75.0370.0760.00  
>800x600   75.0072.1960.32  
>720x576   50.00  
>720x480   59.94  
>640x480   75.0072.8159.94  
> DP-0 disconnected (normal left inverted right x axis y axis)
> DP-1 disconnected (normal left inverted right x axis y axis)
> DP-2 disconnected (normal left inverted right x axis y axis)
> DP-3 disconnected (normal left inverted right x axis y axis)
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#849041: dgit: psuedomerge commits have no author.

[peter green]

On 04/01/17 22:03, Ian Jackson wrote:

Control: severity -1 critical

peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):

Unfortunately I ran into a problem. It seems that the psuedomerge
commits generated by dgit have no author: field and this makes it
impossible to push them to github.

I have discovered that there are problems only with the import-dsc
pseudomerges, but also of the ones made by --overwrite.

Because nothing on the server notices (and afaict there is no way with
the git version currently on the Debian server to stop this), these
commits have become part of public history.

I have a script that can be used to fix the commits but of course the only way 
to fix them is to change history and that has obvious downsides.

http://stackoverflow.com/a/41275543/5083516

Bug#850060: 2.0.874-2~exp1 issues

[Andrew Patterson]

I have been testing 2.0.874-2~exp1 and found the following issues:

1. In debian/extra/initramfs.local-top and
debian/extra/initramfs.local-bottom /sbin/iscsuio creates a pid file
in /run/iscsiuio.pid. You cannot override it on the command-line. The
--pidfile option for start-stop-daemon should point to this location
instead of /run/initramfs/iscsiuio.pid.

2. The /sbin/iscsiuio deamon is trying to create a logfile in
/var/log/iscsiuio.log. The /var/log directory does not exist in the
initramfs. I do not know if this is causing a problem (perhaps related
to #1).

3. The iscsiuio daemon is dieing before or during iscsistart -b. I am
investigating why. It works fine when run after boot.

4. The commit 02c3051 "Don't ignore offloading NICs in iscsistart"
will cause the interface to be configured in both iscsistart -N and in
iscsistart -b for cards with iscsi hardware offload. I suspect we
instead need a flag in iscsistart to bring up the NIC in iscsistart
regardless if the NIC uses an offloadable driver. The local-top script
can use this flag if /sbin/iscsiuio is not present, e.g.,

ISCSISTART_FLAGS=""
if [ ! -x /sbin/iscsiuio ] ; then
   ISCSISTART_FLAGS="-S"
fi
.
.
.
modprobe iscsi_ibft
iscsistart -N $ISCSISTART_FLAGS

The iscsistart code would have to be modified to add support for this
flag. Alternatively, iscsistart could check for the presence of
/sbin/iscsiuio and "do the right thing".

-- 
Andrew Patterson
Hewlett-Packard Enterprise

Bug#850104: ncl FTBFS on the hppa/parisc architecture

[Helge Deller]

Confirmed, the attached patch fixes build of ncl package on the hppa/parisc 
architecture.
Can you please apply the attached patch to the next upload of ncl?

Thanks,
Helge
diff -up ./config/ymake.org ./config/ymake
--- ./config/ymake.org	2017-01-04 16:46:23.259282723 +0100
+++ ./config/ymake	2017-01-04 16:46:40.611281478 +0100
@@ -385,6 +385,7 @@ caseLinux:
 casemip*:
 casesparc*:
 casearm*:
+caseparisc*:
 caseppc*:
 caseaarch64*:
 casealpha:

Bug#850193: RFS: forge/0.9.2-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: forge
  Version : 0.9.2-2
  Upstream Author : ArrayFire
* URL : https://github.com/arrayfire/forge
* License : BSD
  Section : libs

It builds those binary packages:

  forge-doc  - documentation for forge
  libforge-dev - development files for forge
  libforge0  - high-performance OpenGL visualization

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

  https://mentors.debian.net/package/forge

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

  dget -x https://mentors.debian.net/debian/pool/main/f/forge/forge_0.9.2-2.dsc

Successful build on debomatic:

  http://debomatic-amd64.debian.net/distribution#unstable/forge/0.9.2-2/buildlog

Changes since the last upload:

  * Cherry-pick upstream patch facilitating builds with system
libraries.
New patch 0003-Consistent-definition-of-USE_SYSTEM-flags-
for-glbind.patch
  * Force use of system dependencies via the USE_SYSTEM
flags.
Reason: fixes FTBFS during reproducible builds
  * Add missing
build dependency on OpenGL.
Reason: fixes FTBFS on sparc64
  * Add
support for the nodoc build profile.
  * Add patch fixing spelling
errors reported by Lintian.
New patch 0004-Fix-spelling-errors.patch

Regards,
Ghislain Vaillant

Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress

[Ondrej Novy]

Hi,

2017-01-04 16:31 GMT+01:00 Thomas Goirand :

> Please file a bug against ftp.debian.org to get the package removed.
>

Maybe orphan it first?

-- 
Best regards
 Ondřej Nový

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

Bug#850171: forgot to add it should be in section 12.1 https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1

[shirish शिरीष]

Hi all,

Though I thought I had added it, the change will need to be in section 12.1

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

Bug#814218: lua-ldap: Add support for Lua 5.2

[Jason A. Donenfeld]

If anybody would like to take over my lualdap fork, I'd be happy to
transfer commit access.

https://git.zx2c4.com/lualdap

Bug#849602: not a bug

[Mike Hommey]

On Wed, Jan 04, 2017 at 10:24:06PM +0530, shirish शिरीष wrote:
> at bottom :-
> 
> On 04/01/2017, Patrick Mutwiri  wrote:
> > thats how fonts are installed.
> >
> >
> > this is not a bug.
> >
> >
> >
> >
> > *Kind Regards,*
> >
> >
> > Patrick Mutwiri / _dev
> >
> > +254 727 542 899
> >
> > Nairobi, Kenya
> >
> > http://patric.xyz
> >
> > [image: Twitter]  [image: Facebook]
> >  [image: Google +]
> >  [image: LinkedIn]
> >  [image: Instagram]
> >  [image: Github]
> >  [image: Stack Overflow]
> > 
> >
> 
> It is a bug exactly because of the way Jonas has described. If there
> has to be a font which needs to be installed, it should be installed
> system-wide where other packages could also use the font if they
> wanted/needed.
> 
> Having it installed it system-wide with a symlink to a custom location
> is how it has been done for a long time and do not need see a need to
> have it special-cased just because it's mozilla.
> 
> The font should be installed and be available .
> 
> I just tried -
> 
> └─[$] fc-list | grep emoji
>  [$]
> 
> and as can be seen it didn't give any output.
> 
> This has also been shared in debian-policy
> https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.5
> 
> Hope the above gives a bit more insight why we think it's an issue.

I'll gladly symlink to a system font if it exists, but I'm not going to
have firefox provide an EmojiOne font package, because it's a separate
project and there's no reason one of the things that uses it provides it.

I'm also not interested in maintaining one more package.

So please feel free to file a RFP.

Mike

Bug#814218: lua-ldap: Add support for Lua 5.2

[Luca Capello]

tags 814218  + moreinfo
thanks

Hi there,

sorry for the delay, mostly due to real life and the fact that the
servers (with Prosody + lua-ldap) I administer are still on wheezy.

On Tue, 09 Feb 2016 14:33:53 +0530, Avinash Sultanpur wrote:
> The pdns-recursor is compiled with liblua5.2-0 and this package does
> not have support for Lua 5.2 which makes it unusable with Power DNS.
> 
> There are a couple of open pull requests on Github which add support
> for Lua 5.2. Please merge them in order to support Lua 5.2.
> 
> https://github.com/luaforge/lualdap/pulls

I am sorry, but after having tried for 2 weeks now I have given up
trying to understand where the lualdap sources reside, here some
comments:

- 

  AFAIK still the "official" repository, but development has never
  started on it, except for the 2 pulls requests.

  Yet, there are 13 forks on GitHub only!

- 
  
   


  If I read history correctly, some of the more prominent forks, now all
  stalled.

- 
   

  I do not understand why 2 different repositories from the same author
  and no indications that they are the same :-(

- 

  This should be the official follow-up, but as far as I could see
  nothing from the other forks (nor even the "official" one by
  bdellegrazie) has been integrated:


 

  Indeed, on LuaRocks the bdellegrazie's fork is listed:


  
- 
   

  A very recent fork, wait, not even a Git fork but history rewritten...
  
I am aware of the poor maintenance in Debian, entirely due to my fault,
at least in term of all-the-upstream-sources following.

IMHO the best thing should be to ask for removal, especially given the
various upstream sources and to not give a false idea of what is being
installed.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#850192: kcov: new upstream release v32 available

[Michael Prokop]

Package: kcov
Version: 25+dfsg-1
Severity: wishlist

Hi,

upstream released v32 on 22nd of November 2016 (see
https://github.com/SimonKagstrom/kcov/releases), would be nice to
have a more recent version available in Debian.
(Except for i386 with its v25+dfsg-1 in unstable we're stuck at
v11-1 for stable, testing and unstable :-/)

regards,
-mika-

Bug#849041: dgit: psuedomerge commits have no author.

[Ian Jackson]

Control: severity -1 critical

peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):
> Unfortunately I ran into a problem. It seems that the psuedomerge 
> commits generated by dgit have no author: field and this makes it 
> impossible to push them to github.

I have discovered that there are problems only with the import-dsc
pseudomerges, but also of the ones made by --overwrite.

Because nothing on the server notices (and afaict there is no way with
the git version currently on the Debian server to stop this), these
commits have become part of public history.

This is terrible and must be stopped at once.

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#850168: lintian should have checks for manual pages to see if they have an EXAMPlES section

[anarcat]

Control: severity -1 wishlist

I agree!

I often find myself frustrated by more obscure bits of software where I
would love to see some EXAMPLES sections to help me get started.

Maybe this could be a "Informative" or "Pedantic" level instead of
"Warning"? It certainly shouldn't be at the "Error" level, or at least
not worse than the current "manpage missing" message.

Thanks!

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


signature.asc
Description: Digital signature