Bug#871554: curl: CVE-2017-1000101: URL globbing out of bounds read

[Salvatore Bonaccorso]

Source: curl
Version: 7.38.0-4
Severity: important
Tags: upstream patch security fixed-upstream

Hi,

the following vulnerability was published for curl.

CVE-2017-1000101[0]:
URL globbing out of bounds read

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-2017-1000101
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000101
[1] https://curl.haxx.se/docs/adv_20170809A.html

Regards,
Salvatore

Bug#866601: RFS: segyio/1.2.0-1 [ITP: #864710]

[Jørgen Kvalsvik]

The .so and .a are installed by make install, but I'm manually invoking 
dh_install to bind it to a particular package (after tip from another debian 
maintainer), in order to not need a .install-file. Is this wrong?

From: Andrey Rahmatullin 
Sent: Tuesday, August 8, 2017 8:53:38 PM
To: Jørgen Kvalsvik
Cc: 866...@bugs.debian.org
Subject: Re: Bug#866601: RFS: segyio/1.2.0-1 [ITP: #864710]

On Tue, Aug 08, 2017 at 08:38:13AM +, Jørgen Kvalsvik wrote:
> >  Why is the lib installed by code in debian/rules? The upstream build
> > system should do that and it seems it does that, at least partially.
>
> I'm afraid I don't understand what this means, can you point me to an example?
Example of what?
I mean the debian/rules lines which copy .so.* and .a and make the .so
link. Usually this is done by make install.

--
WBR, wRAR


---
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorized use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you

Bug#871555: curl: CVE-2017-1000100: TFTP sends more than buffer size

[Salvatore Bonaccorso]

Source: curl
Version: 7.38.0-4
Severity: important
Tags: patch security upstream fixed-upstream

Hi,

the following vulnerability was published for curl.

CVE-2017-1000100[0]:
TFTP sends more than buffer size

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-2017-1000100
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000100
[1] https://curl.haxx.se/docs/adv_20170809B.html

Regards,
Salvatore

Bug#871556: libvigraimpex: several tests failing in Gridgraph Test Dimension 3

[Daniel Stender]

Source: libvigraimpex
Version: 1.10.0+git20160211.167be93+dfsg-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

With the latest upload there are FTBFS problems on some archs.


Running test_gridgraph
cd 
/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/obj/test/gridgraph 
&& ./run_test_gridgraph.sh
Entering test suite Gridgraph Test
Entering test suite Gridgraph Test Dimension 2
All (38) tests passed in test suite Gridgraph Test Dimension 2
Leaving test suite Gridgraph Test Dimension 2
Entering test suite Gridgraph Test Dimension 3

Failure in NeighborhoodTests::testIndirectNeighborhood()
Assertion failed: neighborOffsets[k] == -neighborOffsets[neighborCount-1-k] 
[(-1, -1, -1) != (-1, 1, -1)] 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:183)

Failure in (&GridGraphTests::template testNeighborIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: target(*e, g) == *n [(1, -1, 0) != (1, -1, 0)] 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:744)

Failure in (&GridGraphTests::template testNeighborIterator)()
Assertion failed: source(*e, g) == *j [(0, -2, 0) != (0, 0, 0)] 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:743)

Failure in (&GridGraphTests::template testBackNeighborIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: target(*e, g) == *n [(0, -1, 0) != (0, -1, 0)] 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:940)

Failure in (&GridGraphTests::template 
testBackNeighborIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: target(*e, g) == *n [(0, -1, 0) != (0, -1, 0)] 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:940)

Failure in (&GridGraphTests::template testEdgeIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: !(e == lemon::INVALID) 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:1062)

Failure in (&GridGraphTests::template testEdgeIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: !(e == lemon::INVALID) 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:1062)

Failure in (&GridGraphTests::template testArcIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: !(e == lemon::INVALID) 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:1143)

Failure in (&GridGraphTests::template testArcIterator)()
Unexpected Contract exception:  
Precondition violation!
Index out of bounds
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/include/vigra/multi_array.hxx:999)

Last checkpoint: !(e == lemon::INVALID) 
(/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/gridgraph/test.cxx:1143)

9 of 38 tests failed in test suite Gridgraph Test Dimension 3
Leaving test suite Gridgraph Test Dimension 3

9 of 76 tests failed in test suite Gridgraph Test
Leaving test suite Gridgraph Test

test/gridgraph/CMakeFiles/test_gridgraph.dir/build.make:123: recipe for target 
'test/gridgraph/test_gridgraph' failed
make[5]: *** [test/gridgraph/test_gridgraph] Error 1
make[5]: *** Deleting file 'test/gridgraph/test_gridgraph'
make[5]: Leaving directory 
'/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/obj'
CMakeFiles/Makefile2:1895: recipe for target 
'test/gridgraph/CMakeFiles/test_gridgraph.dir/all' failed


DS

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

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

Bug#871543: broken init script

[Jörg Frings-Fürst]

severity 871543 important
tags 871543 + moreinfo
thanks


Hello Philippe,

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

Please can you test the init script with the changed line:


start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
  --retry 10 --exec $DAEMON

Many thanks.

Stretch use systemd as default init system. So I set the severity to
important.

CU
Jörg


Am Dienstag, den 08.08.2017, 21:14 -0400 schrieb Philippe Grégoire:
> Package: sane-utils
> Version: 1.0.25-4.1
> Severity: grave
> 
> Hi,
> 
> The saned init script is broken:
> 
> # sh /etc/init.d/saned stop
> Stopping SANE network scanner server: sanedstart-stop-daemon: invalid 
> schedule item (must be [-], -,  or 
> 'forever'
> Try 'start-stop-daemon --help' for more information.
> 
> 
> The offending line:
> 
>  start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
>  --retry --exec $DAEMON
> 
> 
>  From start-stop-daemon(8):
> 
>  -R, --retry timeout|schedule
> 
> 
> Updating the package broke due to this and subsequent invocation
> of apt fails; so this affects the system as a whole.
> 
> 
> Thanks
> 
> Philippe
> 
-- 
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
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  330dfaa3e4985d5c45f5730bd2c21693c2c5e04e

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#871557: mixmaster: segmentation fault in DES key handling

[Benedikt Spranger]

Package: mixmaster
Version: 3.0.0-9
Severity: grave
Tags: patch

Dear Maintainer,

the conversion to use libssl 1.1 renders the package allmost unusable
due to segmentation faults in DES key handling.
DES_set_key() does not allocate memory. After converting
"des_key_schedule X" to "DES_key_schedule *X" DES_set_key() tries to
access memory through an uninitialized pointer. Change conversion to
"DES_key_schedule X" and adapt the usage from "X" to "&X".

Regards
Bene
diff -ruNp mixmaster-3.0.0.orig/debian/patches/mixmaster-libssl-1.1.patch mixmaster-3.0.0/debian/patches/mixmaster-libssl-1.1.patch
--- mixmaster-3.0.0.orig/debian/patches/mixmaster-libssl-1.1.patch	2017-07-02 19:28:00.0 +0200
+++ mixmaster-3.0.0/debian/patches/mixmaster-libssl-1.1.patch	2017-08-08 21:50:58.703847144 +0200
@@ -176,9 +176,9 @@ Migrate to libssl 1.1
 -  des_key_schedule ks2;
 -  des_key_schedule ks3;
 -  des_cblock i;
-+  DES_key_schedule *ks1;
-+  DES_key_schedule *ks2;
-+  DES_key_schedule *ks3;
++  DES_key_schedule ks1;
++  DES_key_schedule ks2;
++  DES_key_schedule ks3;
 +  DES_cblock i;
  
assert(enc == ENCRYPT || enc == DECRYPT);
@@ -188,16 +188,16 @@ Migrate to libssl 1.1
memcpy(i, iv->data, 8);	/* leave iv buffer unchanged */
 -  des_set_key((const_des_cblock *) key->data, ks1);
 -  des_set_key((const_des_cblock *) (key->data + 8), ks2);
-+  DES_set_key((const_DES_cblock *) key->data, ks1);
-+  DES_set_key((const_DES_cblock *) (key->data + 8), ks2);
++  DES_set_key((const_DES_cblock *) key->data, &ks1);
++  DES_set_key((const_DES_cblock *) (key->data + 8), &ks2);
if (key->length == 16)
 -des_set_key((const_des_cblock *) key->data, ks3);
-+DES_set_key((const_DES_cblock *) key->data, ks3);
++DES_set_key((const_DES_cblock *) key->data, &ks3);
else
 -des_set_key((const_des_cblock *) (key->data + 16), ks3);
 -  des_ede3_cbc_encrypt(buf->data, buf->data, buf->length, ks1, ks2, ks3,
-+DES_set_key((const_DES_cblock *) (key->data + 16), ks3);
-+  DES_ede3_cbc_encrypt(buf->data, buf->data, buf->length, ks1, ks2, ks3,
++DES_set_key((const_DES_cblock *) (key->data + 16), &ks3);
++  DES_ede3_cbc_encrypt(buf->data, buf->data, buf->length, &ks1, &ks2, &ks3,
  		   &i, enc);
return (0);
  }
@@ -208,9 +208,9 @@ Migrate to libssl 1.1
 -  des_key_schedule ks1;
 -  des_key_schedule ks2;
 -  des_key_schedule ks3;
-+  DES_key_schedule *ks1;
-+  DES_key_schedule *ks2;
-+  DES_key_schedule *ks3;
++  DES_key_schedule ks1;
++  DES_key_schedule ks2;
++  DES_key_schedule ks3;
  
assert(enc == ENCRYPT || enc == DECRYPT);
assert(key->length == 24 && iv->length == 8);
@@ -220,10 +220,10 @@ Migrate to libssl 1.1
 -  des_set_key((const_des_cblock *) (key->data + 16), ks3);
 -  des_ede3_cfb64_encrypt(buf->data, buf->data, buf->length, ks1, ks2, ks3,
 -			(des_cblock *) iv->data, &n, enc);
-+  DES_set_key((const_DES_cblock *) key->data, ks1);
-+  DES_set_key((const_DES_cblock *) (key->data + 8), ks2);
-+  DES_set_key((const_DES_cblock *) (key->data + 16), ks3);
-+  DES_ede3_cfb64_encrypt(buf->data, buf->data, buf->length, ks1, ks2, ks3,
++  DES_set_key((const_DES_cblock *) key->data, &ks1);
++  DES_set_key((const_DES_cblock *) (key->data + 8), &ks2);
++  DES_set_key((const_DES_cblock *) (key->data + 16), &ks3);
++  DES_ede3_cfb64_encrypt(buf->data, buf->data, buf->length, &ks1, &ks2, &ks3,
 +			(DES_cblock *) iv->data, &n, enc);
return (0);
  }
@@ -240,9 +240,9 @@ Migrate to libssl 1.1
 -  des_key_schedule ks1;
 -  des_key_schedule ks2;
 -  des_key_schedule ks3;
-+  DES_key_schedule *ks1;
-+  DES_key_schedule *ks2;
-+  DES_key_schedule *ks3;
++  DES_key_schedule ks1;
++  DES_key_schedule ks2;
++  DES_key_schedule ks3;
SHA_CTX c;
  
assert(key->length == 25);
@@ -253,38 +253,44 @@ Migrate to libssl 1.1
 -  des_set_key((const_des_cblock *) (key->data + 1), ks1);
 -  des_set_key((const_des_cblock *) (key->data + 9), ks2);
 -  des_set_key((const_des_cblock *) (key->data+ 17), ks3);
-+  DES_set_key((const_DES_cblock *) (key->data + 1), ks1);
-+  DES_set_key((const_DES_cblock *) (key->data + 9), ks2);
-+  DES_set_key((const_DES_cblock *) (key->data+ 17), ks3);
++  DES_set_key((const_DES_cblock *) (key->data + 1), &ks1);
++  DES_set_key((const_DES_cblock *) (key->data + 9), &ks2);
++  DES_set_key((const_DES_cblock *) (key->data+ 17), &ks3);
  
if (mdc) {
  mdc = 1;
-@@ -186,21 +186,21 @@
+@@ -186,22 +186,23 @@
  SHA1_Update(&c, in->data, in->length);
}
n = 0;
 -  des_ede3_cfb64_encrypt(out->data + mdc, out->data + mdc, 10, ks1, ks2, ks3, &iv, &n,
-+  DES_ede3_cfb64_encrypt(out->data + mdc, out->data + mdc, 10, ks1, ks2, ks3, &iv, &n,
- 			 ENCRYPT);
+-			 ENCRYPT);
++  DES_ede3_cfb64_encrypt(out->data + mdc, out->data + mdc, 10,
++			 &ks1, &ks2, &ks3, &iv, &n, ENCRYPT);
if (!mdc) {
  iv[6] = iv[0], iv[7] = iv[1];
  memcpy(iv, out->data + 2, 6);
  n = 0;
}
 -  des_ede3_cfb64_encrypt(in->data, out->data + 10 + mdc, in->length, ks1, ks2, ks3,
-+  DE

Bug#871353: scap-security-guide: FTBFS: unable to parse output/guide.xml

[Philippe Thierry]

Le 7 août 2017 18:00:24 GMT+02:00, Lucas Nussbaum  a écrit :
>Source: scap-security-guide
>Version: 0.1.31-4
>Severity: serious
>Tags: buster sid
>User: debian...@lists.debian.org
>Usertags: qa-ftbfs-20170807 qa-ftbfs
>Justification: FTBFS on amd64
>
>Hi,
>
>During a rebuild of all packages in sid, your package failed to build
>on
>amd64.
>
>Relevant part (hopefully):
>> make[3]: Entering directory '/<>/Fedora'
>> /bin/sh: 1: Syntax error: Bad fd number
>> mkdir -p output/
>> cp ../shared/xccdf/shared_guide.xml output/
>> xsltproc --stringparam SHARED_RP "/<>/shared" -o
>output/shorthand.xml input/guide.xslt output/guide.xml
>> warning: failed to load external entity "output/guide.xml"
>> unable to parse output/guide.xml
>> ../shared/product-make.include:65: recipe for target
>'output/shorthand.xml' failed
>> make[3]: *** [output/shorthand.xml] Error 6
>
>The full build log is available from:
>http://aws-logs.debian.net/2017/08/07/scap-security-guide_0.1.31-4_unstable.log
>
>A list of current common problems and possible solutions is available
>at
>http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
>contribute!
>
>About the archive rebuild: The rebuild was done on EC2 VM instances
>from
>Amazon Web Services, using a clean, minimal and up-to-date chroot.
>Every
>failed build was retried once to eliminate random failures.

Hello Lucas,

Ack. I'll take a look at this. I'm currently working on a major update of this 
package.
-- 
 O   Philippe Thierry. 
/Y\/   GPG: 7010 9a3c e210 763e 6341 4581 c257 b91b cdaf c1ea
o#o   (sent from my smartphone)

Bug#870786: texlive-bin: Make source package bootstrappable

[Norbert Preining]

Hi Daniel,

as I said, I moved the jar building to src:texlive-extra, and removed the
jdk deps and all the building stuff from texlive-bin.

Both packages are uploaded now. Could you please check that this did
really fix it for you?

Thanks

Norbert

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

Bug#871049: linux: please enable MMC_SDHCI_XENON

[Uwe Kleine-König]

Control: tag 871049 + pending

Hello Christoph,

> Please consider enabling MMC_SDHCI_XENON on the 4.12 and later
> kernels. With this modification I can successfully boot plain debian
> kernels from Espressobin using the SD card.
> 
> it needs two patches for devicetree which should be on the way for
> 4.14 latest:
> 
> http://git.infradead.org/linux-mvebu.git/commit/9be778f6c6d8f90ff2fad88d1770e2a7843aee43
> http://git.infradead.org/linux-mvebu.git/commit/1208d2f0c84120d4e3eb2caf663a9a8b784b38ba

I committed the following changes to master:

http://deb.li/Dg4x
http://deb.li/QjfU
 
so in the next upload for 4.12 your SD card should be functional.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#871481: [pkg-fgfs-crew] Bug#871481: flightgear-data-base: Hard dependency on fonts-liberation

[Vladimir K]

Sorry, for some reason I thought that fonts with the same name would be chosen 
alphabetically. At least that was what motivated me to purge v1 while finally 
installing v2 in attempt to make text look sane again after recent fontconfig 
changes. A faulty memory of some old discussion perhaps.

Never mind then, false alarm.

Since all liberation fonts are supposed to be of the same metrics, *in theory* 
swapping them in Flightgear would do no harm. But you never know with hardcoded 
stuff.

Bug#870054: freefem++: scalapack and blacs not found at build time

[Dimitrios Eftaxiopoulos]

Hello Drew,

Thanks for the bug report.

Στις Σάββατο, 29 Ιουλίου 2017 6:13:09 Μ.Μ. EEST γράψατε:
> Source: freefem++
> Version: 3.47+dfsg1-1
> Severity: normal
> 
> blacs is about to be removed from the Debian archives, replaced by
> scalapack2.0 (now in experimental).  So the configuration for the
> freefem++ build will need to be updated to match. configure will need
> to point the blacs library at -lscalapack$ff_with_mpi instead of
> -lblacsCinit$ff_with_mpi, etc.
> 
> Actually there's another problem. Inspecting the current build logs,
> neither blacs nor scalapack (the old versions currently still in
> unstable) are currently being found at build time.  The logs (amd64)
> report:
> checking check hypre... yes
> checking check superlu_dist... no
> checking check superlu... yes
> checking check superlu4... no
> checking check blacs... no
> checking check scalapack... no
> checking check scotch... no
> checking check ptscotch... no
> checking check metis... no
> checking check metis... yes
> checking check parmetis... no
> 
> That should be fixed first, then it will be more clear how to
> reconfigure for blacs in scalapack2.0.

I will see what has to be done omce I will try to upload the current (3.56) 
version of freefem++. Upstream have updated the configuration process.

Cheers
Dimitris

> 
> Cheers,
> Drew
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#852436: cups-browsed uses 100% CPU (Stretch)

[Cédric Dufour - Idiap Research Institute]

Hello,
I confirm this issue is still present is current Debian Stable/Stretch and 
renders CUPS unusable in network printing environments.
I could backport the packages from testing or experimental, but then I would 
miss the updates from the Debian Security team (and looking at the updates 
history of CUPS filters/browsed in Debian OldStable/Jessie, it is not something 
I'm looking forwards to)
Can we hope in seeing this issue also fixed in Debian Stable/Stretch ?
Thanks for your efforts,
Cédric
-- 
Cédric Dufour @ Idiap Research Institute

Bug#870597: filetea: Please upgrade package to 0.1.18 to support reverse proxy

[Alberto Garcia]

On Thu, Aug 03, 2017 at 01:31:22PM +0530, njoseph wrote:

> The current version of package filetea on Debian doesn't support
> running the filetea server behind a reverse proxy. This feature has
> been introduced in version 0.1.18. Please upgrade the package to the
> release 0.1.18.

Hi, it seems that FileTea 0.1.18 does not build with the latest
published version of EventDance (0.1.28), I'll discuss it with
upstream first.

Berto

Bug#870677: nvidia-kernel-dkms: Doesn't compile with kernel 4.11 (and probably later)

[Luca Boccassi]

On Mon, 2017-08-07 at 03:12 +0200, Andreas Beckmann wrote:
> On 2017-08-04 03:09, Jiri Palecek wrote:
> > Package: nvidia-kernel-dkms
> > Version: 378.13-1
> 
> Hi Luca,
> 
> I tried to backport two patches from 340 (couldn't find the place
> where the third should be applied now), but that is not sufficient
> ...
> 
> conftest result changes with these patches applied (this may already
> indicate the problem):
> 4.10.0-trunk-amd64 -> 4.11.0-1-amd64
> 
> -#undef NV_VM_OPS_FAULT_REMOVED_VMA_ARG
> +#define NV_VM_OPS_FAULT_REMOVED_VMA_ARG
> 
> -#define NV_DRM_HELPER_MODE_FILL_FB_STRUCT_HAS_CONST_MODE_CMD_ARG
> +#undef NV_DRM_HELPER_MODE_FILL_FB_STRUCT_HAS_CONST_MODE_CMD_ARG
> 
> 
> and it is failing here:
> 
>   if [ "-pg" = "-pg" ]; then if [ /usr/src/modules/nvidia-
> kernel/nvidia-uvm/uvm8_gpu.o != "scripts/mod/empty.o" ]; then
> ./scripts/recordmcount  "/usr/src/modules/nvidia-kernel/nvidia-
> uvm/uvm8_gpu.o"; fi; fi;
>    gcc-6 -Wp,-MD,/usr/src/modules/nvidia-kernel/nvidia-
> uvm/.uvm8_gpu_isr.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-linux-
> gnu/6/include -I/usr/src/linux-headers-4.11.0-1-
> common/arch/x86/include -I./arch/x86/includ
> e/generated/uapi -I./arch/x86/include/generated  -I/usr/src/linux-
> headers-4.11.0-1-common/include -I./include -I/usr/src/linux-headers-
> 4.11.0-1-common/arch/x86/include/uapi -I/usr/src/linux-headers-
> 4.11.0-1-common/
> include/uapi -I./include/generated/uapi -include /usr/src/linux-
> headers-4.11.0-1-common/include/linux/kconfig.h  -
> I/usr/src/modules/nvidia-kernel -I/usr/src/modules/nvidia-kernel
> -D__KERNEL__ -Wall -Wundef -Wstrict
> -prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-
> implicit-function-declaration -Wno-format-security -std=gnu89 -fno-
> PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-
> jumps=1 -falig
> n-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3
> -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-
> at-a-time -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAM
> E=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1
> -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1
> -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1
> -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-c
> ompare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-
> checks -Wno-frame-address -O2 --param=allow-store-data-races=0
> -DCC_HAVE_ASM_GOTO -Wframe-larger-than=2048 -fstack-protector-strong
> -Wno-unused-but-se
> t-variable -Wno-unused-const-variable -fno-var-tracking-assignments
> -g -pg -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-
> pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-
> int -Werr
> or=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-
> types  -I/usr/src/modules/nvidia-kernel/common/inc  -
> I/usr/src/modules/nvidia-kernel -Wall -MD -Wsign-compare -Wno-cast-
> qual -Wno-error -D__KERNEL
> __ -DMODULE -DNVRM -DNV_VERSION_STRING=\"378.13\" -Wno-unused-
> function -Wuninitialized -fno-strict-aliasing -mno-red-zone
> -mcmodel=kernel -DNV_UVM_ENABLE -Wno-sign-compare -Wno-format-extra-
> args -Werror=undef -O2 -
> DNVIDIA_UVM_ENABLED -DNVIDIA_UNDEF_LEGACY_BIT_MACROS -DLinux
> -D__linux__  -I/usr/src/modules/nvidia-kernel/nvidia-uvm  -DMODULE  -
> DKBUILD_BASENAME='"uvm8_gpu_isr"'  -DKBUILD_MODNAME='"nvidia_uvm"' -c
> -o /usr/src/mo
> dules/nvidia-kernel/nvidia-uvm/.tmp_uvm8_gpu_isr.o
> /usr/src/modules/nvidia-kernel/nvidia-uvm/uvm8_gpu_isr.c
> In file included from /usr/src/modules/nvidia-kernel/nvidia-
> uvm/uvm8_global.h:29:0,
>  from /usr/src/modules/nvidia-kernel/nvidia-
> uvm/uvm8_gpu_isr.c:24:
> /usr/src/modules/nvidia-kernel/nvidia-uvm/uvm8_gpu_isr.c: In function
> 'uvm_gpu_replayable_faults_isr_unlock':
> /usr/src/modules/nvidia-kernel/nvidia-uvm/uvm8_gpu_isr.c:273:28:
> error: passing argument 1 of 'atomic_read' from incompatible pointer
> type [-Werror=incompatible-pointer-types]
>  UVM_ASSERT(atomic_read(&gpu->gpu_kref.refcount) > 0);
> ^
> /usr/src/modules/nvidia-kernel/nvidia-uvm/uvm_common.h:138:45: note:
> in definition of macro 'UVM_IGNORE_EXPR'
>  #define UVM_IGNORE_EXPR(expr) ((void)sizeof(expr))
>  ^~~~
> /usr/src/modules/nvidia-kernel/nvidia-uvm/uvm_common.h:168:26: note:
> in expansion of macro '_UVM_ASSERT_MSG'
>  #define UVM_ASSERT(expr) _UVM_ASSERT_MSG(expr, #expr, "\n")
>   ^~~
> /usr/src/modules/nvidia-kernel/nvidia-uvm/uvm8_gpu_isr.c:273:5: note:
> in expansion of macro 'UVM_ASSERT'
>  UVM_ASSERT(atomic_read(&gpu->gpu_kref.refcount) > 0);
>  ^~
> In file included from /usr/src/linux-headers-4.11.0-1-
> common/arch/x86/include/asm/msr.h:66:0,
>  from /usr/src/linux-headers-4.11.0-1-
> common/arch/x86/include/asm/processor.h:20,
>  from /usr/src/linux-headers-4.11.0-1-
> common/arch/x86/include/a

Bug#871559: openafs: [INTL:pt] Updated Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: openafs
Version: 1.6.21-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for openafs's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org











# Portuguese translation for openafs debconf messages
# Copyright (C) 2007 Miguel Figueiredo
# This file is distributed under the same license as the openafs package.
#
# Miguel Figueiredo , 2007, 2013.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: openafs 1.4.2-5\n"
"Report-Msgid-Bugs-To: open...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-10 15:27-0500\n"
"PO-Revision-Date: 2017-08-09 09:47+0100\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Gtranslator 2.91.7\n"

#. Type: string
#. Description
#: ../openafs-client.templates:1001
msgid "DB server host names for your home cell:"
msgstr "Nomes de máquinas dos servidores de bases de dados para a sua célula:"

#. Type: string
#. Description
#: ../openafs-client.templates:1001
msgid ""
"AFS uses the file /etc/openafs/CellServDB to hold the list of servers that "
"should be contacted to find parts of a cell.  The cell you claim this "
"workstation belongs to is not in that file.  Enter the host names of the "
"database servers separated by spaces. IMPORTANT: If you are creating a new "
"cell and this machine is to be a database server in that cell, only enter "
"this machine's name; add the other servers later after they are functioning. "
"Also, do not enable the AFS client to start at boot on this server until the "
"cell is configured.  When you are ready you can edit /etc/openafs/afs.conf."
"client to enable the client."
msgstr ""
"O AFS utiliza o ficheiro /etc/openafs/CellServDB para guardar a lista de "
"servidores que devem ser contactados para encontrar partes de uma célula.  A "
"célula que você diz a que esta estação de trabalho pertence não está nesse "
"ficheiro.  Introduza os nomes das máquinas dos servidores de bases de dados "
"separados por espaços. IMPORTANTE: Se está a criar uma nova célula e esta "
"máquina é uma máquina que irá servir a base de dados nessa célula, apenas "
"introduza o nome desta máquina; acrescente depois os outros servidores "
"depois de estes estarem a funcionar. Além disso, não habilite o client AFS "
"para iniciar no arranque neste servidor até que a célula esteja "
"configurada.  Quando você estiver pronto pode editar /etc/openafs/afs.conf."
"client para habilitar o cliente."

#. Type: string
#. Description
#: ../openafs-client.templates:2001
msgid "AFS cell this workstation belongs to:"
msgstr "Célula AFS a que esta estação de trabalho pertence:"

#. Type: string
#. Description
#: ../openafs-client.templates:2001
msgid ""
"AFS filespace is organized into cells or administrative domains. Each "
"workstation belongs to one cell.  Usually the cell is the DNS domain name of "
"the site."
msgstr ""
"O espaço de ficheiros do AFS é organizado em células ou domínios "
"administrativos. Cada estação de trabalho pertence a uma célula.  "
"Normalmente a célula é o nome de domínio DNS do site."

#. Type: string
#. Description
#: ../openafs-client.templates:3001
msgid "Size of AFS cache in kB:"
msgstr "Tamanho da cache AFS em kB:"

#. Type: string
#. Description
#: ../openafs-client.templates:3001
msgid ""
"AFS uses an area of the disk to cache remote files for faster access.  This "
"cache will be mounted on /var/cache/openafs.  It is important that the cache "
"not overfill the partition it is located on.  Often, people find it useful "
"to dedicate a partition to their AFS cache."
msgstr ""
"O AFS utiliza uma área do disco para fazer cache de ficheiros remotos para "
"um acesso mais rápido.  Esta cache irá ser montada em /var/cache/openafs.  É "
"importante que a cache não encha a partição em que está localizada.  Muitas "
"vezes, algumas pessoas acham útil dedicar uma partição para a sua cache AFS."

#. Type: boolean
#. Description
#: ../openafs-client.templates:4001
msgid "Run Openafs client now and at boot?"
msgstr "Correr o cliente Openafs agora e no arranque?"

#. Type: boolean
#. Description
#: ../openafs-client.templates:4001
#| msgid ""
#| "Normally, most users who install the openafs-client package expect AFS to "
#| "be mounted automatically at boot.  However, if you are planning on "
#| "setting up a new cell or are on a laptop, you may not want it started at "
#| "boot time.  If you choose not to start AFS at boot, run /etc/init.d/"
#| "openafs-client force-start to start the client when you wish to run it."
msgid ""
"Normally, most users who install the openafs-client package expect AFS to be "
"mounted autom

Bug#871560: mysql-5.7: [INTL:pt] Updated Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: mysql-5.7
Version: 5.7.18-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for mysql-5.7's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org












# Portuguese translation for mysql-5.7's debconf messages
# Copyright (C) 2006 Miguel Figueiredo 
# This file is distributed under the same license as the mysql-5.7 package.
# Miguel Figueiredo , 2012
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: mysql-5.7 5.7.18-1\n"
"Report-Msgid-Bugs-To: mysql-...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-16 15:13+\n"
"PO-Revision-Date: 2017-08-07 19:34+0100\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:2001
msgid "Really proceed with downgrade?"
msgstr "Deseja mesmo fazer downgrade?"

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:2001
msgid "A file named /var/lib/mysql/debian-*.flag exists on this system."
msgstr ""
"Existe, neste sistema, um ficheiro chamado /var/lib/mysql/debian-*.flag."

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:2001
msgid ""
"Such a file is an indication that a mysql-server package with a higher "
"version has been installed previously."
msgstr ""
"A existência de tal ficheiro é um indicador que anteriormente foi instalado "
"um pacote mysql-server com um número de versão superior."

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:2001
msgid ""
"There is no guarantee that the version you're currently installing will be "
"able to use the current databases."
msgstr ""
"Não existe nenhuma garantia que a versão que está actualmente a instalar "
"seja capaz de utilizar as bases de dados actuais."

#. Type: note
#. Description
#: ../mysql-server-5.7.templates:3001
msgid "Important note for NIS/YP users"
msgstr "Nota importante para utilizadores de NIS/YP"

#. Type: note
#. Description
#: ../mysql-server-5.7.templates:3001
msgid ""
"Using MySQL under NIS/YP requires a mysql user account to be added on the "
"local system with:"
msgstr ""
"Utilizar MySQL com NIS/YP necessita que seja adicionada uma conta de "
"utilizador de mysql ao sistema local com:"

#. Type: note
#. Description
#: ../mysql-server-5.7.templates:3001
msgid ""
"You should also check the permissions and ownership of the /var/lib/mysql "
"directory:"
msgstr ""
"Deve também verificar as permissões e o dono do directório /var/lib/mysql:"

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:4001
msgid "Remove all MySQL databases?"
msgstr "Remover todas as bases de dados MySQL?"

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:4001
msgid ""
"The /var/lib/mysql directory which contains the MySQL databases is about to "
"be removed."
msgstr ""
"O directório /var/lib/mysql que contém as bases de dados MySQL está prestes "
"a ser removido."

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:4001
msgid ""
"This will also erase all data in /var/lib/mysql-files as well as /var/lib/"
"mysql-keyring."
msgstr ""
"Isto irá apagar todos os dados em /var/lib/mysql-files bem como em /var/lib/"
"mysql-keyring."

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:4001
msgid ""
"If you're removing the MySQL package in order to later install a more recent "
"version or if a different mysql-server package is already using it, the data "
"should be kept."
msgstr ""
"Se está a remover o pacote MySQL de modo a posteriormente instalar uma "
"versão mais recente ou se um pacote mysql-server já está os está a utilizar, "
"os dados devem ser mantidos."

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:5001
msgid "Start the MySQL server on boot?"
msgstr "Iniciar o servidor MySQL no arranque?"

#. Type: boolean
#. Description
#: ../mysql-server-5.7.templates:5001
msgid ""
"The MySQL server can be launched automatically at boot time or manually with "
"the '/etc/init.d/mysql start' command."
msgstr ""
"O MySQL pode ser automaticamente lançado no arranque ou manualmente através "
"do comando '/etc/init.d/mysql start'."

#. Type: password
#. Description
#: ../mysql-server-5.7.templates:6001
msgid "New password for the MySQL \"root\" user:"
msgstr "Nova palavra-passe para o utilizador \"root\" do MySQL:"

#. Type: password
#. Description
#: ../mysql-server-5.7.templates:6001
msgid ""
"While not mandatory, it is highly recommended that you set a password for "
"the MySQL administrative \"root\" user."
msgstr ""
"Embora não seja obrigatório, é fortemente recomendado que defina uma palavra-"
"passe para o utilizador administrativo \"root\" do MySQL."

Bug#866601: RFS: segyio/1.2.0-1 [ITP: #864710]

[Andrey Rahmatullin]

On Wed, Aug 09, 2017 at 06:42:40AM +, Jørgen Kvalsvik wrote:
> The .so and .a are installed by make install, but I'm manually invoking
> dh_install to bind it to a particular package (after tip from another
> debian maintainer), in order to not need a .install-file. Is this wrong?
Yes, .install is better than manually invoking dh_install.
You also didn't comment on the manual link creation.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#871561: kismet: [INTL:pt] Updated Portuguese translation for debconf messages

[Traduz - DebianPT]

Package: kismet
Version: 2016.07.R1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for kismet's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .
--
Best regards,

"Traduz" - Portuguese Translation Team
http://www.DebianPT.org












# Portuguese translation for kismet debconf
# Copyright (C) 2012 THE kismet'S COPYRIGHT HOLDER
# This file is distributed under the same license as the kismet package.
# Miguel Figueiredo , 2012.
# Rui Branco , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: kismet 2016.07.R1-1\n"
"Report-Msgid-Bugs-To: kis...@packages.debian.org\n"
"POT-Creation-Date: 2015-11-04 05:39+0100\n"
"PO-Revision-Date: 2017-08-07 19:42+0100\n"
"Last-Translator: Rui Branco \n"
"Language-Team: Portuguese \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../kismet.templates:2001
msgid "Install Kismet \"setuid root\"?"
msgstr "Instalar o Kismet com \"setuid root\"?"

#. Type: boolean
#. Description
#: ../kismet.templates:2001
msgid ""
"Kismet needs root privileges for some of its functions. However, running it "
"as root (\"sudo kismet\") is not recommended, since running all of the code "
"with elevated privileges increases the risk of bugs doing system-wide "
"damage. Instead Kismet can be installed with the \"setuid\" bit set, which "
"will allow it to grant these privileges automatically to the processes that "
"need them, excluding the user interface and packet decoding parts."
msgstr ""
"O Kismet necessita de privilégios de root para algumas das suas funções. No "
"entanto, corrê-lo como root (\"sudo kismet\") não é recomendado, já que "
"correr o código com privilégios elevados aumenta o risco de bugs fazerem "
"estragos em todo o sistema. Em vez disso o Kismet pode ser instalado com o "
"bit \"setuid\" definido, que permite atribuir automaticamente esses "
"privilégios aos processos que necessitem deles, excluindo o interface de "
"utilizador e partes da descodificação de pacotes."

#. Type: boolean
#. Description
#: ../kismet.templates:2001
msgid ""
"Enabling this feature allows users in the \"kismet\" group to run Kismet "
"(and capture packets, change wireless card state, etc), so only thoroughly "
"trusted users should be granted membership of the group."
msgstr ""
"Activar esta funcionalidade permite aos utilizadores do grupo \"kismet\" "
"correrem o Kismet (e capturar pacotes, alterar o estado da placa wireless, "
"etc), por isso apenas deve ser permitida a inclusão no grupo a utilizadores "
"confiáveis."

#. Type: boolean
#. Description
#: ../kismet.templates:2001
msgid ""
"For more detailed information, see section 4 of the Kismet README "
"(\"Suidroot & Security\"), which can be found at /usr/share/doc/kismet/"
"README or \"http://www.kismetwireless.net/README\".";
msgstr ""
"Para mais informação detalhada, veja a secção 4 do README do Kismet "
"(\"Suidroot & Security\"), que pode ser encontrado em /usr/share/doc/kismet/"
"README ou em \"http://www.kismetwireless.net/README\".";

#. Type: string
#. Description
#: ../kismet.templates:3001
msgid "Users to add to the kismet group:"
msgstr "Utilizadores a acrescentar ao grupo kismet:"

#. Type: string
#. Description
#: ../kismet.templates:3001
msgid ""
"Only users in the kismet group are able to use kismet under the setuid model."
msgstr ""
"Apenas os utilizadores do grupo kismet podem utilizar o kismet sob o modelo "
"setuid."

#. Type: string
#. Description
#: ../kismet.templates:3001
msgid ""
"Please specify the users to be added to the group, as a space-separated list."
msgstr ""
"Por favor especifique os utilizadores a serem acrescentados ao grupo, como "
"uma lista separada por espaços."

#. Type: string
#. Description
#: ../kismet.templates:3001
msgid ""
"Note that currently logged-in users who are added to a group will typically "
"need to log out and log in again before it is recognized."
msgstr ""
"Note que os utilizadores actualmente identificados no sistema que sejam "
"acrescentados a um grupo tipicamente irão necessitar de fazer logout e login "
"antes de serem reconhecidos."

#. Type: error
#. Description
#: ../kismet.templates:4001
msgid "The provided user list contains invalid usernames."
msgstr ""
"A lista de utilizadores fornecida contem nomes de utilizadores inválidos."

#. Type: error
#. Description
#: ../kismet.templates:4001
msgid ""
"The users to be added to the kismet group have to be provided in a space-"
"separated list of usernames. It seems that the following usernames are not "
"valid: ${USERS}. Please revise the list."
msgstr ""
"Os utilizadores a serem adicionados ao grupo Kismet tem que ser fornecidos "
"através de uma lista com os nomes de utilizadores separados por espaços. "
"Parece que os seguintes nomes de utilizadores

Bug#855173: ITP status?

[Bas Zoetekouw]

Hi Julian,

I was just about to file my own ITP for keepassxc when I stumpled upon
yours.

Could you give an update on the status?  I'd be happy to help out with
packaging and/or uploading, if you like.

Greetings,
Bas.


signature.asc
Description: OpenPGP digital signature

Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

[Edmund Grimley Evans]

James:

> I think the runtime is working, but this is the testcase from the SIGBUS
> bug which you can use:
>
> ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libx264rgb -f avi 
> libx264rgb.avi -y -hide_banner -nostdin
> ffmpeg -strict -2 -i libx264rgb.avi -t 1 -c:v rawvideo -c:a pcm_s32le -f nut 
> /dev/null -y -hide_banner -nostdin
>
> Since the SIGBUS bug occurs in NEON code, if the runtime detection is
> working, this will _only_ fail on machines with NEON and work on
> non-NEON machines.

This bug was closed while I was sleeping, but I will mention anyway
that with 7:3.3.3-1 those commands give a SIGBUS, as expected, but
only if /proc is mounted.

Presumably with the fixed version, 7:3.3.3-2, performance will be
measurably worse on a system with NEON when /proc is not mounted.

Upstream should probably switch to using getauxval(). Do you want to
suggest it to them?

Bug#870058: xsane failing since stretch upgrade

[Jörg Frings-Fürst]

severity 870058 important
thanks



Hello Daniel,

no answer since 10 days. So I set the severity to important.


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
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

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#868678: autopkgtest: Support Kali in setup-testbed

[Raphael Hertzog]

On Wed, 09 Aug 2017, Martin Pitt wrote:
> Raphaël Hertzog [2017-07-17 17:12 +0200]:
> > /usr/share/autopkgtest/setup-commands/setup-testbed rewrites
> > /etc/apt/sources.list in a way that only works with mirrors whose URL
> > contains "ubuntu" or "debian".
> > 
> > I would like the script to also work for Kali so I propose the following
> > patch:
> 
> Thanks! Applied to git.

Thanks but I would like you to consider my other suggestions in the same
report:

| But it should probably also be smarter for the benefits of all other 
derivatives:
| 
| - not do anything if $MIRROR or $RELEASE is empty
| 
| - rely on /etc/os-release (within the image) to identify the distribution and
|   use the first entry in /etc/apt/sources.list to find the mirror to use (that
|   way you can have a mirror like http://192.168.1.222:/ and still have a
|   working setup-testbed even if your ubuntu mirror does not contain the string
|   ubuntu)

I can understand the second one is a bit involved... but at least the first one 
is easy
to do. If you fail to identify the mirror or the release, don't overwrite the 
sources.list.

Please consider adding this. Thank you.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests

[Alex Riesen]

Package: perl-base
Version: 5.24.1-3+deb9u1
Severity: normal

Dear Maintainer,

when I run the test suite (Git (the VCS, master branch), the perl binary
sometimes crashes in one of its tests. I used the commands below to reproduce
the problem (just let it run, it'll crash eventually):

$ git clone git://git.kernel.org/pub/scm/git/git.git && cd git
$ make USE_LIBPCRE2=YesPlease   (requires curl-dev and openssl-dev, I think...)
$ cd t (the test suite)
$ ulimit -c unlimited
$ rm -rf 'trash directory.t9128-git-svn-cmd-branch'
$ while ./t9128-git-svn-cmd-branch.sh -d -i
do
  echo; echo
  rm -rf 'trash directory.t9128-git-svn-cmd-branch'
done
...
not ok 3 - git svn branch tests
#
#   git svn branch a &&
#   base=$(git rev-parse HEAD:) &&
#   test $base = $(git rev-parse remotes/origin/a:) &&
#   git svn branch -m "created branch b blah" b &&
#   test $base = $(git rev-parse remotes/origin/b:) &&
#   test_must_fail git branch -m "no branchname" &&
#   git svn branch -n c &&
#   test_must_fail git rev-parse remotes/origin/c &&
#   test_must_fail git svn branch a &&
#   git svn branch -t tag1 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag1:) &&
#   git svn branch --tag tag2 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag2:) &&
#   git svn tag tag3 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag3:) &&
#   git svn tag -m "created tag4 foo" tag4 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag4:) &&
#   test_must_fail git svn tag -m "no tagname" &&
#   git svn tag -n tag5 &&
#   test_must_fail git rev-parse remotes/origin/tags/tag5 &&
#   test_must_fail git svn tag tag1
#
$ gdb /usr/bin/perl './trash directory.t9128-git-svn-cmd-branch/core'
...
(gdb) bt full
#0  0x00b2ce983b10 in Perl_sv_clear (my_perl=my_perl@entry=0xb2cefdf010, 
orig_sv=orig_sv@entry=0xb2d00807e8) at sv.c:6582
stash = 
type = 9
sv_type_details = 
iter_sv = 0x0
next_sv = 0x0
sv = 0xb2d00807e8
hash_index = 0
#1  0x00b2ce983da0 in Perl_sv_free2 (my_perl=my_perl@entry=0xb2cefdf010, 
sv=sv@entry=0xb2d00807e8, rc=) at sv.c:6954
No locals.
#2  0x00b2ce8fd8a5 in S_SvREFCNT_dec (sv=0xb2d00807e8, 
my_perl=0xb2cefdf010) at inline.h:166
rc = 
#3  Perl_gp_free (my_perl=my_perl@entry=0xb2cefdf010, gv=gv@entry=0xb2d0080938) 
at gv.c:2568
file_hek = 
hv = 
io = 0xb2d00807e8
form = 0x0
sv = 
cv = 0x0
av = 0x0
gp = 
attempts = 100
#4  0x00b2ce983b74 in Perl_sv_clear (my_perl=my_perl@entry=0xb2cefdf010, 
orig_sv=orig_sv@entry=0xb2d00e92c0) at sv.c:6585
stash = 
type = 9
sv_type_details = 
iter_sv = 0x0
next_sv = 0x0
sv = 0xb2d0080938
hash_index = 0
#5  0x00b2ce983da0 in Perl_sv_free2 (my_perl=my_perl@entry=0xb2cefdf010, 
sv=0xb2d00e92c0, rc=) at sv.c:6954
No locals.
#6  0x00b2ce972ad2 in S_SvREFCNT_dec (sv=, 
my_perl=0xb2cefdf010) at inline.h:166
rc = 
#7  S_hv_delete_common (hash=, d_flags=68, k_flags=, klen=, key=, keysv=, 
hv=0xb2cefdf010, my_perl=0xb2d007db68) at hv.c:1279
xhv = 
first_entry = 
stash = 
entry = 0xb2d00e4828
keysv_hek = 
mro_changes = 
sv = 
oentry = 0xb2d007db68
is_utf8 = false
masked_flags = 
gv = 
#8  Perl_hv_common (my_perl=my_perl@entry=0xb2cefdf010, 
hv=hv@entry=0xb2cfff4e10, keysv=, key=, 
key@entry=0x0, klen=, klen@entry=0, flags=, 
flags@entry=0, action=68, val=0x0, hash=) at hv.c:397
xhv = 
entry = 
oentry = 
sv = 
is_utf8 = false
masked_flags = 
return_svp = 0
keysv_hek = 0x0
#9  0x00b2ce9aca1f in Perl_pp_delete (my_perl=0xb2cefdf010) at pp.c:5061
_p = 
sv = 
mark = 0xb2cf00fed8
origmark = 0
hv = 0xb2cfff4e10
hvtype = 
sp = 0xb2cf00fee0
gimme = 1 '\001'
discard = 4
#10 0x00b2ce976916 in Perl_runops_standard (my_perl=0xb2cefdf010) at 
run.c:41
op = 
#11 0x00b2ce8f4aee in Perl_call_sv (my_perl=my_perl@entry=0xb2cefdf010, 
sv=0xb2cf546fd0, flags=flags@entry=45) at perl.c:2812
myop = {
  op_next = 0x0,
  op_sibling = 0x0,
  op_ppaddr = 0x0,
  op_targ = 0,
  op_type = 0,
  op_opt = 0,
  op_slabbed = 0,
  op_savefree = 0,
  op_static = 0,
  op_folded = 0,
  op_moresib = 0,
  op_spare = 0,
  op_flags = 65 'A',
  op_private = 0 '\000',
  op_first = 0x0,
  op_other = 0x7fffe7a15bf0
}
method_op = {
  op_next = 0x7fffe7a15c78,
  o

Bug#871300: [Pkg-gmagick-im-team] Bug#871300: libmagick++-6.q16-7: requires rebuild against GCC 7 and symbols/shlibs bump

[Bastien Roucaries]

Le 7 août 2017 22:59:06 GMT+02:00, James Cowgill  a écrit :
>Hi,
>
>On 07/08/17 16:55, roucaries bastien wrote:
>> On Mon, Aug 7, 2017 at 4:47 PM,   wrote:
>>> Package: libmagick++-6.q16-7
>>> Version: 8:6.9.7.4+dfsg-16
>>> Severity: serious
>>> Tags: sid buster
>>> User: debian-...@lists.debian.org
>>> Usertags: gcc-7-op-mangling
>>>
>> 
>> I need a change that break ABI, I will release a new version. Does it
>> exist in this case a short cut
>
>If you are going to rename the Debian package and trigger a package
>transition, you do not need to add any of the extra symbols/shlibs
>stuff. You should still build-depend on gcc (>= 4:7) however - I'm not
>sure if all the buildds use GCC 7 by default yet.


 Should i depends on g++7 for libmagick++-dev ?


>Thanks,
>James

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#866634: cairo-dock-plug-ins: diff for NMU version 3.4.1-1.1

[Adrian Bunk]

Control: tags 866634 + patch
Control: tags 866634 + pending

Dear maintainer,

I've prepared an NMU for cairo-dock-plug-ins (versioned as 3.4.1-1.1) 
and uploaded it to DELAYED/10. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru cairo-dock-plug-ins-3.4.1/debian/changelog cairo-dock-plug-ins-3.4.1/debian/changelog
--- cairo-dock-plug-ins-3.4.1/debian/changelog	2016-10-29 22:31:54.0 +0300
+++ cairo-dock-plug-ins-3.4.1/debian/changelog	2017-08-09 12:19:29.0 +0300
@@ -1,3 +1,11 @@
+cairo-dock-plug-ins (3.4.1-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Stop building cairo-dock-weblets-plug-in, it required a version
+of WebKitGTK+ that won't be in buster. (Closes: #866634)
+
+ -- Adrian Bunk   Wed, 09 Aug 2017 12:19:29 +0300
+
 cairo-dock-plug-ins (3.4.1-1) unstable; urgency=medium
 
   * Imported Upstream version 3.4.1.
diff -Nru cairo-dock-plug-ins-3.4.1/debian/control cairo-dock-plug-ins-3.4.1/debian/control
--- cairo-dock-plug-ins-3.4.1/debian/control	2016-10-29 22:31:54.0 +0300
+++ cairo-dock-plug-ins-3.4.1/debian/control	2017-08-09 12:19:06.0 +0300
@@ -33,7 +33,6 @@
  libsensors4-dev,
  libupower-glib-dev,
  libvte-2.91-dev,
- libwebkitgtk-3.0-dev,
  libxklavier-dev,
  libxml2-dev,
  libxtst-dev,
@@ -46,6 +45,7 @@
  ruby-dev,
  valac,
  x11proto-xf86vidmode-dev
+Build-Conflicts: libwebkitgtk-3.0-dev
 Standards-Version: 3.9.8
 Homepage: http://www.glx-dock.org/
 Vcs-Git: https://anonscm.debian.org/git/pkg-cairo-dock/cairo-dock-plug-ins.git
@@ -92,7 +92,6 @@
   cairo-dock-system-monitor-plug-in,
   cairo-dock-dnd2share-plug-in,
   cairo-dock-musicplayer-plug-in,
-  cairo-dock-weblets-plug-in,
   cairo-dock-folders-plug-in,
   cairo-dock-impulse-plug-in,
   cairo-dock-messaging-menu-plug-in,
@@ -621,15 +620,15 @@
  Xfce environment.
  This is auto-activated, so you don't need to activate it.
 
-Package: cairo-dock-weblets-plug-in
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, cairo-dock-plug-in-data (= ${source:Version})
-Breaks: cairo-dock-weblets-plugin (<< 2.4.0~2-1)
-Replaces:  cairo-dock-weblets-plugin(<< 2.4.0~2-1)
-Description: Weblets plug-in for Cairo-dock
- A collection of official plug-ins and applets for cairo-dock.
- .
- This plug-in allows you to show an interactive web page on your desktop.
+#Package: cairo-dock-weblets-plug-in
+#Architecture: any
+#Depends: ${shlibs:Depends}, ${misc:Depends}, cairo-dock-plug-in-data (= ${source:Version})
+#Breaks: cairo-dock-weblets-plugin (<< 2.4.0~2-1)
+#Replaces:  cairo-dock-weblets-plugin(<< 2.4.0~2-1)
+#Description: Weblets plug-in for Cairo-dock
+# A collection of official plug-ins and applets for cairo-dock.
+# .
+# This plug-in allows you to show an interactive web page on your desktop.
 
 Package: cairo-dock-folders-plug-in
 Architecture: any

Bug#871563: manpages-fr-extra outdated

[Laurent Bigonville]

Package: manpages-fr-extra
Version: 20151231
Severity: serious
Tags: sid buster

Hi,

manpages-fr-extra is quite outdated (last upload in 2015), lot of
projects have been updated to newer version and have now newer/updated
manpages or are now shipped by other source packages (like the
shutdown/reboot commands, see bug #828623)

IMVHO, it's better to have no translation at all than having misleading
ones and I'm not sure if this package should be part of buster if it's
not updated in meantime.

I already did some work to update this package but I would like to have
some feedback, see: https://github.com/bigon/manpages-fr-extra

Regards,

Laurent Bigonville

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

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

Bug#867554: rkt: fails to start containers with systemd 233

[Valentin Vidic]

New upstream version wes released to fix the problem with systemd 234:

v1.28.1

This is a minor bugfix release. It does not contain any changes to the
rkt code, but it updates dependencies and runtime versions for bugfixes:

* vendor: update go-systemd to v15 (#3759). rkt stopped working when
  running in a service with systemd v234. This update fixes it.
* scripts: update rkt-builder version to 1.3.0 (#3754). This updates
  the default Go runtime to 1.8, fixing #3738.

-- 
Valentin

Bug#871564: manpages-fr outdated

[Laurent Bigonville]

Source: manpages-fr
Version: 3.65d1p1-1
Severity: serious
Tags: sid buster


Hi,

manpages-fr is quite outdated (last upload in 2014), the upstream
manpages have been updated in the meantime and this package should have
a major update.

IMVHO, it's better to have no translation at all than having misleading
or outdated ones and I'm not sure if this package should be part of
buster if it's not updated in meantime.

The problem seems that upstream for these translated manpages is now
dead/not active anymore. The last release on [0] if for the manpage
version 3.70 (the manpages package in debian is as of today  at version
4.12).

Regards,

Laurent Bigonville

[0] https://alioth.debian.org/frs/?group_id=100455

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

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

Bug#860296: lirc is spamming syslog with messages

[Jörg Frings-Fürst]

Package: lirc
Version: 0.9.4c-9
Followup-For: Bug #860296

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

the same here.

Lirc is installed as a dependency.

Because of spamming the partition overflows and the disks are not going to me
to sleep mode.

So I think the severity important isn't enough, serious is better for this bug.

My suggestion would be to test for the requested devices at startup once and
then use the device hotplug to load the driver and to activate lirc.

CU
Jörg



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

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

Versions of packages lirc depends on:
ii  init-system-helpers  1.49
ii  libasound2   1.1.3-5
ii  libc62.24-12
ii  libftdi1-2   1.3-2+b3
ii  libgcc1  1:7.1.0-10
ii  liblirc-client0  0.9.4c-9
ii  liblirc0 0.9.4c-9
ii  libportaudio219.6.0-1
ii  libstdc++6   7.1.0-10
ii  libsystemd0  234-2
ii  libudev1 234-2
ii  libusb-0.1-4 2:0.1.12-31
ii  libusb-1.0-0 2:1.0.21-2
ii  lsb-base 9.20161125
ii  python3  3.5.3-3

Versions of packages lirc recommends:
pn  gir1.2-vte
ii  python3-gi3.22.0-2+b1
ii  python3-yaml  3.12-1+b1

Versions of packages lirc suggests:
pn  ir-keytable  
pn  lirc-compat-remotes  
pn  lirc-doc 
pn  lirc-drv-irman   
pn  lirc-x   
pn  setserial

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlmK50cACgkQCfifPIyh
0l3lnQ/7Bz39Ub1qzcpgN2jne0yaJImBCw2napgX8Z9MI67wsoHvX+QDPWp5A4fA
pdN42+IZlFPH9zmlZ17GlkrsRrmkWcNDRbOzad1/fiU1af1C46qKIRLrlqeBFWzO
sD49xUNc5VRkVTWjwnoOth/uZX4wgiqqc0YFC4Ov5mKFeipDwT2xX7fuTyT9jsOQ
YJ+MBxCMYIPouRNI02lOiHLBVGn6p5+FHC6qTkNLjP4vhaZj9C5awbrXnXl2aAw2
iUhJiGqZfQsg1nPhuFiDlX60TgGsKG3XWSGupJVGtVf9fzzjWk1hOCV6NzPPb0Nr
0GUrrFiKhfieGGKNCjlqc9Fhv9waDhdQuNKfPpargq0ptM8NgK7iHyXvcqoNnCGo
3o1YCHRyC2H8s9tcgcAUFcM6FCLQej1tbfWBc/w45G1hGR4R2cNEDHT0m5E2j3P/
A0VSOA774XaD9Lo/Vo0CDNPiq0lNtj7Gz4n2W3dYCp5hTKXHm+CLCjpSEychCf4D
5WzEGdAvBkulZfj0fd7KyxzaNrLDtPDnyqmnGN3N+rfvcmCIbsNcxP4TOybn61hw
hrpWTlJ/86dSyLGDfguS82K46/jw5UGPSqhpYTKQyW2THHwzxBa142sWZyw7rKNt
QBUpA5fnilFTW0f+xlOmT2SoWnWQgddyqlsJ5v741fBLSh1QXk0=
=msGQ
-END PGP SIGNATURE-

Bug#871566: swarmkit FTBFS: cannot find package "github.com/docker/docker/api/types"

[Adrian Bunk]

Source: swarmkit
Version: 1.12.0+git20170201.779.1c7f003d-3
Severity: serious

https://buildd.debian.org/status/package.php?p=swarmkit&suite=sid

...
# Perform regular build
dh_auto_build
go install 
-gcflags=\"-trimpath=/<>/swarmkit-1.12.0\+git20170201.779.1c7f003d/obj-aarch64-linux-gnu/src\"
 
-asmflags=\"-trimpath=/<>/swarmkit-1.12.0\+git20170201.779.1c7f003d/obj-aarch64-linux-gnu/src\"
 -v -p 1 github.com/docker/swarmkit github.com/docker/swarmkit/agent 
github.com/docker/swarmkit/agent/exec 
github.com/docker/swarmkit/agent/exec/container 
github.com/docker/swarmkit/agent/secrets github.com/docker/swarmkit/api 
github.com/docker/swarmkit/api/duration github.com/docker/swarmkit/api/equality 
github.com/docker/swarmkit/api/naming github.com/docker/swarmkit/api/timestamp 
github.com/docker/swarmkit/ca github.com/docker/swarmkit/ca/testutils 
github.com/docker/swarmkit/cli 
github.com/docker/swarmkit/cmd/external-ca-example 
github.com/docker/swarmkit/cmd/protoc-gen-gogoswarm 
github.com/docker/swarmkit/cmd/swarm-bench 
github.com/docker/swarmkit/cmd/swarmctl 
github.com/docker/swarmkit/cmd/swarmctl/cluster 
github.com/docker/swarmkit/cmd/swarmctl/common github.c
 om/docker/swarmkit/cmd/swarmctl/network 
github.com/docker/swarmkit/cmd/swarmctl/node 
github.com/docker/swarmkit/cmd/swarmctl/secret 
github.com/docker/swarmkit/cmd/swarmctl/service 
github.com/docker/swarmkit/cmd/swarmctl/service/flagparser 
github.com/docker/swarmkit/cmd/swarmctl/task 
github.com/docker/swarmkit/cmd/swarmd github.com/docker/swarmkit/identity 
github.com/docker/swarmkit/integration github.com/docker/swarmkit/ioutils 
github.com/docker/swarmkit/log github.com/docker/swarmkit/manager 
github.com/docker/swarmkit/manager/allocator 
github.com/docker/swarmkit/manager/allocator/networkallocator 
github.com/docker/swarmkit/manager/constraint 
github.com/docker/swarmkit/manager/controlapi 
github.com/docker/swarmkit/manager/dispatcher 
github.com/docker/swarmkit/manager/dispatcher/heartbeat 
github.com/docker/swarmkit/manager/encryption 
github.com/docker/swarmkit/manager/health 
github.com/docker/swarmkit/manager/keymanager 
github.com/docker/swarmkit/manager/logbroker github.com/docker/s
 warmkit/manager/orchestrator 
github.com/docker/swarmkit/manager/orchestrator/constraintenforcer 
github.com/docker/swarmkit/manager/orchestrator/global 
github.com/docker/swarmkit/manager/orchestrator/replicated 
github.com/docker/swarmkit/manager/orchestrator/restart 
github.com/docker/swarmkit/manager/orchestrator/taskreaper 
github.com/docker/swarmkit/manager/orchestrator/testutils 
github.com/docker/swarmkit/manager/orchestrator/update 
github.com/docker/swarmkit/manager/raftselector 
github.com/docker/swarmkit/manager/resourceapi 
github.com/docker/swarmkit/manager/scheduler 
github.com/docker/swarmkit/manager/state 
github.com/docker/swarmkit/manager/state/raft 
github.com/docker/swarmkit/manager/state/raft/membership 
github.com/docker/swarmkit/manager/state/raft/storage 
github.com/docker/swarmkit/manager/state/raft/testutils 
github.com/docker/swarmkit/manager/state/store github.com/docker/swarmkit/node 
github.com/docker/swarmkit/protobuf/plugin 
github.com/docker/swarmkit/protobuf/plugin/
 authenticatedwrapper github.com/docker/swarmkit/protobuf/plugin/deepcopy 
github.com/docker/swarmkit/protobuf/plugin/deepcopy/test 
github.com/docker/swarmkit/protobuf/plugin/raftproxy 
github.com/docker/swarmkit/protobuf/plugin/raftproxy/test 
github.com/docker/swarmkit/protobuf/ptypes github.com/docker/swarmkit/remotes 
github.com/docker/swarmkit/template 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/pkg/crc 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/pkg/fileutil 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/pkg/idutil 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/pkg/ioutil 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/pkg/pbutil 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/raft 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/raft/raftpb 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/snap 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/snap/snappb 
github.com/docker/swarmkit/vendor/github.
 com/coreos/etcd/wal 
github.com/docker/swarmkit/vendor/github.com/coreos/etcd/wal/walpb 
github.com/docker/swarmkit/version github.com/docker/swarmkit/watch 
github.com/docker/swarmkit/xnet
src/github.com/docker/swarmkit/agent/exec/container/adapter.go:11:2: cannot 
find package "github.com/docker/docker/api/types" in any of:

/<>/swarmkit-1.12.0+git20170201.779.1c7f003d/obj-aarch64-linux-gnu/src/github.com/docker/swarmkit/vendor/github.com/docker/docker/api/types
 (vendor tree)
/usr/lib/go-1.8/src/github.com/docker/docker/api/types (from $GOROOT)

/<>/swarmkit-1.12.0+git20170201.779.1c7f003d/obj-aarch64-linux-gnu/src/github.com/docker/docker/api/types
 (from $GOPATH)
src/github.com/docker/swarmkit/agent/exec/container/api_cl

Bug#871565: ffmpeg FTBSF on ppc64el: test failures

[Adrian Bunk]

Source: ffmpeg
Version: 7:3.3.3-2
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=ppc64el&ver=7%3A3.3.3-2&stamp=1502249633&raw=0

...
TESTacodec-tta
/<>/tests/fate-run.sh fate-acodec-tta "" "" 
"/<>/debian/standard" 'enc_dec wav tests/data/asynth-44100-2.wav 
tta "-b:a 128k -c tta " wav "-c pcm_s16le " -keep' '' 
'/<>/tests/ref/acodec/tta' '' '1' '' '' '' '' '' '2' '' ''
 /<>/debian/standard/ffmpeg -nostdin -nostats -cpuflags all -f wav 
-threads 1 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact 
-fflags +bitexact -hwaccel none -threads 1 -thread_type frame+slice -i 
/<>/debian/standard/tests/data/asynth-44100-2.wav -threads 1 -idct 
simple -dct fastint -b:a 128k -c tta -flags +bitexact -sws_flags 
+accurate_rnd+bitexact -fflags +bitexact -f tta -y 
/<>/debian/standard/tests/data/fate/acodec-tta.tta
 /<>/debian/standard/ffmpeg -nostdin -nostats -cpuflags all -flags 
+bitexact -fflags +bitexact -hwaccel none -threads 1 -thread_type frame+slice 
-i /<>/debian/standard/tests/data/fate/acodec-ra144.rm -c:a 
pcm_s16le -fflags +bitexact -f wav -
stddev: 6741.57 PSNR: 19.75 MAXDIFF:45411 bytes:96000/96000
stddev: |6741.57 - 4777| >= 1
Test acodec-ra144 failed. Look at tests/data/fate/acodec-ra144.err for details.
ffmpeg version 3.3.3-2 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7 (Debian 7.1.0-12)
  configuration: --prefix=/usr --extra-version=2 --toolchain=hardened 
--libdir=/usr/lib/powerpc64le-linux-gnu 
--incdir=/usr/include/powerpc64le-linux-gnu --enable-gpl --disable-stripping 
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa 
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca 
--enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame 
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse 
--enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr 
--enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame 
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp 
--enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx 
--enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 
--enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv -
 -enable-libx264 --enable-shared
  libavutil  55. 58.100 / 55. 58.100
  libavcodec 57. 89.100 / 57. 89.100
  libavformat57. 71.100 / 57. 71.100
  libavdevice57.  6.100 / 57.  6.100
  libavfilter 6. 82.100 /  6. 82.100
  libavresample   3.  5.  0 /  3.  5.  0
  libswscale  4.  6.100 /  4.  6.100
  libswresample   2.  7.100 /  2.  7.100
  libpostproc54.  5.100 / 54.  5.100
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, wav, from 
'/<>/debian/standard/tests/data/asynth-8000-1.wav':
  Duration: 00:00:06.00, bitrate: 128 kb/s
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 8000 Hz, mono, s16, 
128 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> ra_144 (real_144))
Output #0, rm, to 
'/<>/debian/standard/tests/data/fate/acodec-ra144.rm':
  Metadata:
encoder : Lavf57.71.100
Stream #0:0: Audio: ra_144 (real_144) (lpcJ / 0x4A63706C), 8000 Hz, mono, 
s16, 8 kb/s
Metadata:
  encoder : Lavc57.89.100 real_144
size=  10kB time=00:00:06.00 bitrate=  13.2kbits/s speed=21.7x
video:0kB audio:6kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: 64.435219%
ffmpeg version 3.3.3-2 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7 (Debian 7.1.0-12)
  configuration: --prefix=/usr --extra-version=2 --toolchain=hardened 
--libdir=/usr/lib/powerpc64le-linux-gnu 
--incdir=/usr/include/powerpc64le-linux-gnu --enable-gpl --disable-stripping 
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa 
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca 
--enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame 
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse 
--enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr 
--enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame 
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp 
--enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx 
--enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 
--enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv -
 -enable-libx264 --enable-shared
  libavutil  55. 58.100 / 55. 58.100
  libavcodec 57. 89.100 / 57. 89.100
  libavformat57. 71.100 / 57. 71.100
  libavdevice57.  6.100 / 57.  6.100
  libavfilter 6. 82.100 /  6. 82.100
  libavresample   3.  5.  0 /  3.  5.  0
  libswscale 

Bug#870073: [Pkg-mozext-maintainers] Bug#870073: gnome-keyring hijacking gpg-agent on jessie

[Paul van der Vlis]

Op 08-08-17 om 00:57 schreef Daniel Kahn Gillmor:> On Mon 2017-08-07
19:57:41 +0200, Paul van der Vlis wrote:
>> I did now as root:
>> dpkg-divert --local --rename --divert \
>>   /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable \
>>   --add /etc/xdg/autostart/gnome-keyring-gpg.desktop
>>
>> And I logged out and in again. Now I can use Enigmail, but it works not
>> really nice. Before I could turn-on encrypting and signing using the
>> menu. Now it says default "encrypt (auto)" and it's not clear if it's
>> encrypting or not. If I click on it, it says "encrypt" without "(auto)"
>> and then it works, but I cannot turn it off anymore using the menu. But
>> maybe this is new and normal.
> 
> Are you talking about during message composition?

Yes.

> there is a big enigmail toolbar that should be at the top of each
> composition window.  it has two buttons, one for signing, and one for
> encryption.  those buttons should be very clear whether they're selected
> or not.  If you don't have the toolbar, maybe its been customized away?

That's possible.

> can you do "View | Toolbars | Enigmail Toolbar" ?

This helps!

> I think maybe the other report that you're making here is that the
> checkboxes on thunderbird 53 menus on jessie are not visible.

Correct.

> I can confirm that:



> I've cloned this bug to document that problem and bring it to the
> attention of the thunderbird devs.

Nice to hear.

>> So I think what other people with this probleme have to do is:
>> -
>> echo "use-agent" >> ~/.gnupg/gpg.conf
>>
>> sudo dpkg-divert --local --rename --divert \
>>   /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable \
>>   --add /etc/xdg/autostart/gnome-keyring-gpg.desktop
>>
>> logout and login again.
>> -
> 
> That sounds plausible.  i could even consider shipping the
> dpkg-diversion in the jessie version of enigmail, if the gnome-keyring
> maintainers are OK with it.  (or they could ship an update in jessie
> that disables it too)

Maybe think about it. A message after the upgrade of Enigmail would be
an simple alternative.

> But really, users should be encouraged to upgrade to stretch :)
I have many customers who buy a laptop with Debian from me, but do not
come when there is a new version. And organizations what cannot upgrade
before much testing. Jessie has security support, and that is important.

With regards,
Paul van der Vlis

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#871568: Debian OVAL Files Improvement

[Noam Rathaus]

Package: security.debian.org

Currently the Debian OVAL lack (critical) information from the files,
specifically the severity setting of the patch.

I wanted to ask if it would be possible for the XML files that the script
you run will include the  rating of the DSA advisory?

The DSA advisory itself doesn't include the severity but the CVE do, so
scraping the information from the NIST site would allow you to know what is
the severity ( by taking each CVE's CVSSv3 score and seeing which number is
"highest" )

If you agree to this, and need help getting this to work, I can lend a hand
- I can provide code on how to "harvest" the NVD NIST site for the
information, or take the information from NDV NIST's XML files (which they
provide)

--

Thanks,
Noam Rathaus
Beyond Security

PGP Key ID: 2D24B275B1EB4475 (Exp 2018-03)

Bug#871567: libffcall1-dev: linking with libcallback fails on ppc64el: undefined reference to `tramp_r'

[Adrian Bunk]

Package: libffcall1-dev
Version: 1.10+cvs20100619-4
Severity: serious
Control: affects -1 src:mlpcap

mlpcap FTBFS on ppc64el:

https://buildd.debian.org/status/fetch.php?pkg=mlpcap&arch=ppc64el&ver=0.9-17&stamp=1502205676&raw=0

...
checking for alloc_trampoline_r in -lcallback... no
configure: error: can't find callback library.
/usr/share/cdbs/1/class/autotools.mk:44: recipe for target 
'debian/stamp-autotools' failed
make: *** [debian/stamp-autotools] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2



The root problem is:

(sid_ppc64el-dchroot)bunk@plummer:~/build$ cat test.c
char alloc_trampoline_r();
int main()
{
return alloc_trampoline_r();
}
(sid_ppc64el-dchroot)bunk@plummer:~/build$ gcc -O2 -Wall test.c -lcallback
/usr/lib/gcc/powerpc64le-linux-gnu/7/../../../powerpc64le-linux-gnu/libcallback.so:
 undefined reference to `tramp_r'
collect2: error: ld returned 1 exit status
(sid_ppc64el-dchroot)bunk@plummer:~/build$


The same works on amd64.

autoconf uses a dummy (and in this case incorrect) prototype
in AC_CHECK_LIB checks. The bug is the link error, after
successful linking it is not expected that the resulting
binary built from this testcase works.

Bug#864714: task crm_node:16894 blocked for more than 120 seconds.

[Russell Mosemann]

Package: src:linux
Version: 4.9.30-2+deb9u2~bpo8+1
Severity: important
 
Aug 09 03:39:08 vhost082 kernel: INFO: task crm_node:16894 blocked for more 
than 120 seconds.
Aug 09 03:39:08 vhost082 kernel:   Not tainted 4.9.0-0.bpo.3-amd64 #1 
Debian 4.9.30-2+deb9u2~bpo8+1
Aug 09 03:39:08 vhost082 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 09 03:39:08 vhost082 kernel: crm_nodeD0 16894  1 0x0004
Aug 09 03:39:08 vhost082 kernel:  8a28ed224000  
8a373856f000 8a27740dd100
Aug 09 03:39:08 vhost082 kernel:  8a373f2587c0 9f588a14f780 
bae02a4d 
Aug 09 03:39:08 vhost082 kernel:   3f258828 
0001 8a27740dd100
Aug 09 03:39:08 vhost082 kernel: Call Trace:
Aug 09 03:39:08 vhost082 kernel:  [] ? __schedule+0x23d/0x6d0
Aug 09 03:39:08 vhost082 kernel:  [] ? 
bit_wait_timeout+0x90/0x90
Aug 09 03:39:08 vhost082 kernel:  [] ? schedule+0x32/0x80
Aug 09 03:39:08 vhost082 kernel:  [] ? 
schedule_timeout+0x249/0x300
Aug 09 03:39:08 vhost082 kernel:  [] ? 
lock_timer_base+0x6d/0x90
Aug 09 03:39:08 vhost082 kernel:  [] ? 
bit_wait_timeout+0x90/0x90
Aug 09 03:39:08 vhost082 kernel:  [] ? 
io_schedule_timeout+0xb4/0x130
Aug 09 03:39:08 vhost082 kernel:  [] ? 
prepare_to_wait_exclusive+0x57/0x80
Aug 09 03:39:08 vhost082 kernel:  [] ? bit_wait_io+0x17/0x60
Aug 09 03:39:08 vhost082 kernel:  [] ? 
__wait_on_bit_lock+0x7f/0xb0
Aug 09 03:39:08 vhost082 kernel:  [] ? __lock_page+0x7f/0xa0
Aug 09 03:39:08 vhost082 kernel:  [] ? 
autoremove_wake_function+0x40/0x40
Aug 09 03:39:08 vhost082 kernel:  [] ? 
pagecache_get_page+0x21b/0x2b0
Aug 09 03:39:08 vhost082 kernel:  [] ? 
shmem_unused_huge_shrink+0x1eb/0x360
Aug 09 03:39:08 vhost082 kernel:  [] ? 
super_cache_scan+0x184/0x190
Aug 09 03:39:08 vhost082 kernel:  [] ? shrink_slab+0x24a/0x450
Aug 09 03:39:08 vhost082 kernel:  [] ? shrink_node+0x10a/0x320
Aug 09 03:39:08 vhost082 kernel:  [] ? 
do_try_to_free_pages+0xfb/0x330
Aug 09 03:39:08 vhost082 kernel:  [] ? 
try_to_free_pages+0xfc/0x1b0
Aug 09 03:39:08 vhost082 kernel:  [] ? 
__alloc_pages_slowpath+0x319/0xb60
Aug 09 03:39:08 vhost082 kernel:  [] ? 
__alloc_pages_nodemask+0x208/0x270
Aug 09 03:39:08 vhost082 kernel:  [] ? 
alloc_pages_current+0x8a/0x110
Aug 09 03:39:08 vhost082 kernel:  [] ? pte_alloc_one+0x13/0x40
Aug 09 03:39:08 vhost082 kernel:  [] ? __pte_alloc+0x19/0x100
Aug 09 03:39:08 vhost082 kernel:  [] ? 
alloc_set_pte+0x521/0x590
Aug 09 03:39:08 vhost082 kernel:  [] ? 
handle_mm_fault+0x801/0x16b0
Aug 09 03:39:08 vhost082 kernel:  [] ? 
__do_page_fault+0x253/0x510
Aug 09 03:39:08 vhost082 kernel:  [] ? page_fault+0x28/0x30

Bug#855829: [Python-modules-team] Bug#855829: Possible solution

[Brian May]

Neil Williams  writes:

> I've pushed a new temporary branch [0] (which can be removed once
> reviewed) which uses the removal method in lieu of upstream merging the
> pull request [1] and making a new upstream release. Please review.

Looks fine to me. At least on a temp basis. Uploaded.
-- 
Brian May 

Bug#864714: task crm_node:15263 blocked for more than 120 seconds.

[Russell Mosemann]

Package: src:linux
Version: 4.9.30-2+deb9u2~bpo8+1
Severity: important
 
Aug 08 23:14:25 vhost032 kernel: INFO: task crm_node:15263 blocked for more 
than 120 seconds.
Aug 08 23:14:25 vhost032 kernel:   Not tainted 4.9.0-0.bpo.3-amd64 #1 
Debian 4.9.30-2+deb9u2~bpo8+1
Aug 08 23:14:25 vhost032 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 08 23:14:25 vhost032 kernel: crm_nodeD0 15263  1 0x0004
Aug 08 23:14:25 vhost032 kernel:  8c98ccb47400  
8ca738719040 8c990a36a040
Aug 08 23:14:25 vhost032 kernel:  8ca73f4187c0 ba5387dff780 
84802a4d 0282
Aug 08 23:14:25 vhost032 kernel:  0282 049a 
0298 8c990a36a040
Aug 08 23:14:25 vhost032 kernel: Call Trace:
Aug 08 23:14:25 vhost032 kernel:  [] ? __schedule+0x23d/0x6d0
Aug 08 23:14:25 vhost032 kernel:  [] ? 
bit_wait_timeout+0x90/0x90
Aug 08 23:14:25 vhost032 kernel:  [] ? schedule+0x32/0x80
Aug 08 23:14:25 vhost032 kernel:  [] ? 
schedule_timeout+0x249/0x300
Aug 08 23:14:25 vhost032 kernel:  [] ? 
find_busiest_group+0x3e/0x4d0
Aug 08 23:14:25 vhost032 kernel:  [] ? 
bit_wait_timeout+0x90/0x90
Aug 08 23:14:25 vhost032 kernel:  [] ? 
io_schedule_timeout+0xb4/0x130
Aug 08 23:14:25 vhost032 kernel:  [] ? 
prepare_to_wait_exclusive+0x57/0x80
Aug 08 23:14:25 vhost032 kernel:  [] ? bit_wait_io+0x17/0x60
Aug 08 23:14:25 vhost032 kernel:  [] ? 
__wait_on_bit_lock+0x7f/0xb0
Aug 08 23:14:25 vhost032 kernel:  [] ? __lock_page+0x7f/0xa0
Aug 08 23:14:25 vhost032 kernel:  [] ? 
autoremove_wake_function+0x40/0x40
Aug 08 23:14:25 vhost032 kernel:  [] ? 
pagecache_get_page+0x21b/0x2b0
Aug 08 23:14:25 vhost032 kernel:  [] ? 
shmem_unused_huge_shrink+0x1eb/0x360
Aug 08 23:14:25 vhost032 kernel:  [] ? 
super_cache_scan+0x184/0x190
Aug 08 23:14:25 vhost032 kernel:  [] ? shrink_slab+0x24a/0x450
Aug 08 23:14:25 vhost032 kernel:  [] ? shrink_node+0x10a/0x320
Aug 08 23:14:25 vhost032 kernel:  [] ? 
do_try_to_free_pages+0xfb/0x330
Aug 08 23:14:25 vhost032 kernel:  [] ? 
try_to_free_pages+0xfc/0x1b0
Aug 08 23:14:25 vhost032 kernel:  [] ? 
__alloc_pages_slowpath+0x319/0xb60
Aug 08 23:14:25 vhost032 kernel:  [] ? 
__alloc_pages_nodemask+0x208/0x270
Aug 08 23:14:25 vhost032 kernel:  [] ? 
alloc_pages_current+0x8a/0x110
Aug 08 23:14:25 vhost032 kernel:  [] ? pte_alloc_one+0x13/0x40
Aug 08 23:14:25 vhost032 kernel:  [] ? __pte_alloc+0x19/0x100
Aug 08 23:14:25 vhost032 kernel:  [] ? 
alloc_set_pte+0x521/0x590
Aug 08 23:14:25 vhost032 kernel:  [] ? 
handle_mm_fault+0x801/0x16b0
Aug 08 23:14:25 vhost032 kernel:  [] ? 
__do_page_fault+0x253/0x510
Aug 08 23:14:25 vhost032 kernel:  [] ? page_fault+0x28/0x30

Bug#871569: installation-reports: offline machine, install from ISO images -- use case feels neglected

[Christian Pernegger]

Package: installation-reports
Severity: normal

Hello,

the idea was to install and use stretch on an offline machine. No
network access available or needed, now or in future, but all the
software in Debian at its disposal.
I decided that the best way to achieve this would be to obtain a full
set of ISO images, since there's signed official releases of those, dd
them to a bunch of USB drives and use them as if they were CDs. (Maybe
a partial mirror on an external HDD would have been the better
option?)

Issues:
1) The installer booted off and recognised the first "Bluray" just
fine, but at no point did it ask me if I had and wanted to add any
other discs. It didn't even point me to the possibility of adding some
via apt-cdrom. This was contrary to expectations, considering there's
a set.
Work around: add using apt-cdrom after installation has finished.

2) Neither the installer nor the system installed by it seem to have
any concept of ISO data being on something else than a physical disc
in an optical drive by default. After the first boot the first
"Bluray" wasn't found any longer by apt and friends, as the path to
the "optical drive" had changed.
Work around: change the /media/cdrom entry in /etc/fstab to use
/dev/disk/by-path/ and stick to one USB port, possibly tweak an
apt-cdrom option or two, I forget.

3) After having added all three images I ran aptitude update -- out of
habit but also because I'd gotten no indication that that wouldn't be
neccessary. That spewed messages about not having a [signed, I
presume?] Release file, "... can't be authenticated and is
therefore potentially dangerous to use". See also #807996.
Now that is *scary*, especially if you've done your homework and
verified the ISOs every which way. 
I'm still not quite sure what's up with that, I've a hard time
believing that the official ISOs simply don't have signed release
files. According to Google that seems to have been the case in the
past, but with the recent push to deprecate unsigned repositories that
seems unlikly. In a way that ties back to item 2 -- chances are the
ISO is not on a physically immutable medium nowadays.

4) When installing stuff, aptitude will sometimes output a warning
about dpkg having completed fewer actions than expected. The
likelyhood seems to increase with the number of packages installed /
if the job spans multiple "discs". I'm not sure if it's actually
detrimental, but in a couple of cases I could've sworn I needed a few
tries to get everything to install.

5) Running MATE with default settings breaks this setup again, because
it'll automount the USB drive as soon as it's connected (ignoring the
mount point set for that in fstab ...). If you manually unmount it
using the GUI, it doesn't just unmount, it removes the drive from
existence, as far as Linux is concerned.
Work around: disable everything to do with automount.


Don't get me wrong, it works quite well now and it wasn't hard to
figure out, but I've been using Debian for close to twenty years
now. Someone newish might be stranded. And sure, the majority of
installs will have network access, but surely the official images' use
case isn't just "boot off it and possibly save a bit on bandwidth"?
(Somehow that reminds me of physical copies of Steam games ...)
It's possible that sets of fixed-size images aren't the right approach
for today, maybe a few boot images plus signed "mirror dumps" in
various sizes are the way to go, but in any case I believe that
(mostly) offline systems should still be supported as a first class
option.

Regards
Christian Pernegger


-- Package-specific info:

Boot method: ISO image dd'ed to USB flash drive
Image version: debian-9.1.0-amd64-BD-[123].iso
Date: End of July, 2017

Machine: 2016 netbook, Intel
Partitions: n/a


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

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

Comments/Problems:

*) Having to configure network (in order to set hostname) on a system
with no NIC is a tad counter-intuitive.

**) TBH, using base 10 units for measuring any kind of
computer memory drives me up the wall. Why can't the installer's
partitioning tool support base 2 suffixes as well? Have you tried
creating two partitions that are exactly the same size with that
thing? Hint: it doesn't work.
Anyway, in previous versions I used to be able to do my partitioning
on the (other) console using fdisk, then use the installer as normal,
in stretch that confuses it no end. It would not format pre-existing
partitions nor give me an option to do so, not even if the partition
was zeroed. As a result it'd fail to mount the af

Bug#871570: git FTBFS on i386: t7006-pager.sh test failure

[Adrian Bunk]

Source: git
Version: 1:2.14.0-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=git&arch=i386&ver=1%3A2.14.0-1&stamp=1502132890&raw=0

...
expecting success: 
(
sane_unset LESS LV &&
PAGER="env >pager-env.out; wc" &&
export PAGER &&
PATH="$(git --exec-path):$PATH" &&
export PATH &&
test_terminal sh -c ". git-sh-setup && git_pager"
) &&
grep ^LESS= pager-env.out &&
grep ^LV= pager-env.out

wc: 'standard input': Input/output error
  0   0   0
not ok 6 - LESS and LV envvars set by git-sh-setup
...
# still have 3 known breakage(s)
# failed 1 among remaining 75 test(s)
1..78
Makefile:49: recipe for target 't7006-pager.sh' failed
make[4]: *** [t7006-pager.sh] Error 1

Bug#871568: Debian OVAL Files Improvement

[Moritz Muehlenhoff]

On Wed, Aug 09, 2017 at 02:16:54PM +0300, Noam Rathaus wrote:
> Package: security.debian.org
> 
> Currently the Debian OVAL lack (critical) information from the files,
> specifically the severity setting of the patch.
> 
> I wanted to ask if it would be possible for the XML files that the script
> you run will include the  rating of the DSA advisory?

DSA advisories intentionally don't have a severity rating and we're not
planning to add one (since the severity depends strongly on local factors).

I don't feel comfortable pulling in external CVSS classifications that we
don't have any control over.

Cheers,
Moritz

Bug#871568: Debian OVAL Files Improvement

[Noam Rathaus]

Hi,

I see, but it doesn't answer the problem of how can someone judge the
severity of DSA-X against DSA-Y and say which one is more important?

Yes local factors can take precedence, for example having a local user vs
not having local users - note that CVSSv3 takes this into account with the
part of authentication.

You should note that RedHat, Ubnutu, CentOS, and others provide a severity
rating, either based on the NIST NVD, or based on some internal "mechanism"

But they provide that information to assist their customers to understand
the threat

It would be disappointing if this is not done for Debian as well.


On Wed, Aug 9, 2017 at 2:33 PM, Moritz Muehlenhoff  wrote:

> On Wed, Aug 09, 2017 at 02:16:54PM +0300, Noam Rathaus wrote:
> > Package: security.debian.org
> >
> > Currently the Debian OVAL lack (critical) information from the files,
> > specifically the severity setting of the patch.
> >
> > I wanted to ask if it would be possible for the XML files that the script
> > you run will include the  rating of the DSA advisory?
>
> DSA advisories intentionally don't have a severity rating and we're not
> planning to add one (since the severity depends strongly on local factors).
>
> I don't feel comfortable pulling in external CVSS classifications that we
> don't have any control over.
>
> Cheers,
> Moritz
>



-- 

Thanks,
Noam Rathaus
Beyond Security

PGP Key ID: 2D24B275B1EB4475 (Exp 2018-03)

Bug#871568: Debian OVAL Files Improvement

[Moritz Mühlenhoff]

On Wed, Aug 09, 2017 at 02:36:27PM +0300, Noam Rathaus wrote:
> Hi,
> 
> I see, but it doesn't answer the problem of how can someone judge the
> severity of DSA-X against DSA-Y and say which one is more important?

Well, read the advisory text and make your own assessment :-)

> You should note that RedHat, Ubnutu, CentOS, and others provide a severity
> rating, either based on the NIST NVD, or based on some internal "mechanism"
> 
> But they provide that information to assist their customers to understand
> the threat
> 
> It would be disappointing if this is not done for Debian as well.

We have no interest in doing that. If there's really demand for something
like that, feel free to setup a website which classifies Debian updates
by severity.

Cheers,
   Moritz

Bug#871568: Debian OVAL Files Improvement

[Sébastien Delafond]

On Aug/09, Moritz Muehlenhoff wrote:
> > I wanted to ask if it would be possible for the XML files that the
> > script you run will include the  rating of the DSA
> > advisory?
> 
> DSA advisories intentionally don't have a severity rating and we're
> not planning to add one (since the severity depends strongly on local
> factors).
> 
> I don't feel comfortable pulling in external CVSS classifications that
> we don't have any control over.

I've quickly looked into this, and it turns out RedHat does include a
severity in their OVAL definitions, but SuSE does not.

I agree that severity is most often highly depending on local context,
and is therefore a metric that's difficult to come up with in the
general sense. However, our OVAL definitions are basically per-CVE
entries, we could potentially tie the NVD NIST severity to each one.

I'm more worried about the implementation, though: as we don't store
this information ourselves anywhere, it would force us to scrape the NVD
NIST website for *all* CVEs affecting Debian, several times a day, which
hardly seems like a good idea.

Cheers,

--Seb

Bug#777330: xvier: please make the build reproducible

[Chris Lamb]

tags 777330 + pending patch
thanks

I've uploaded xvier 1.0-7.6 to DELAYED/15:
  
  xvier (1.0-7.6) unstable; urgency=medium
  
* Non-maintainer upload.
* Make the build reproducible. (Closes: #777330)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for xvier_1.0-7.5 xvier_1.0-7.6

 changelog |7 +++
 rules |4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff -u xvier-1.0/debian/changelog xvier-1.0/debian/changelog
--- xvier-1.0/debian/changelog
+++ xvier-1.0/debian/changelog
@@ -1,3 +1,10 @@
+xvier (1.0-7.6) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make the build reproducible. (Closes: #777330)
+
+ -- Chris Lamb   Wed, 09 Aug 2017 07:52:20 -0400
+
 xvier (1.0-7.5) unstable; urgency=high
 
   * Non-maintainer upload.
diff -u xvier-1.0/debian/rules xvier-1.0/debian/rules
--- xvier-1.0/debian/rules
+++ xvier-1.0/debian/rules
@@ -31,12 +31,12 @@
$(tmp)/usr/share/man/man6 $(tmp)/usr/share/doc/xvier
install -s -m 755 xvier xvier_prog $(tmp)/usr/games
strip --remove-section=.comment --remove-section=.note 
$(tmp)/usr/games/*
-   gzip -c9 xvier.man > $(tmp)/usr/share/man/man6/xvier.6x.gz
+   gzip -c9n xvier.man > $(tmp)/usr/share/man/man6/xvier.6x.gz
ln -s xvier.6x.gz $(tmp)/usr/share/man/man6/xvier_prog.6x.gz
install -m 755 debian/postinst debian/postrm $(tmp)/DEBIAN
install -m 644 README $(tmp)/usr/share/doc/xvier
install -m 644 mini-xvier.xpm $(tmp)/usr/share/pixmaps
-   gzip -c9 debian/changelog > 
$(tmp)/usr/share/doc/xvier/changelog.Debian.gz
+   gzip -c9n debian/changelog > 
$(tmp)/usr/share/doc/xvier/changelog.Debian.gz
install -m 644 debian/copyright $(tmp)/usr/share/doc/xvier/copyright
install -m 644 debian/menu $(tmp)/usr/share/menu/xvier
dpkg-shlibdeps $(tmp)/usr/games/*

Bug#866024: Followup for removal of pygpgme from unstable

[Dr. Tobias Quathamer]

Dear Jonathan,

a few days ago, pygpgme has been autoremoved from testing. Are you going
to ask ftpmaster to remove it from unstable now, as announced in #846314
and #866026? Or does anything still prevent this?

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#869878: [#476427]: Re: Bug#869878: mirror submission for mirror.nl.10gbps.io

[CDN77.com - Tech]

##- Please type your reply above this line -##

Hi,

> Just select the names backing this services:
> 
> > > Archive-upstream: ftp.nl.debian.org
> > > CDImage-upstream: ftp2.de.debian.org
> 
> ftp2.de.debian.org. 600 IN CNAME ftp.halifax.rwth-aachen.de.

this is done.

Regards,
Jaroslav

-- 
Best Regards,
Jaroslav ShejbalCDN77.com | Content Delivery Network
m: t...@cdn77.com | sa...@cdn77.com
t: +1-718-427-9911 (US)
t: +44 (0) 20 3514 2399 (UK)
w: http://www.cdn77.com

Ticket History
===


ow...@bugs.debian.org Posted On: 08 August 2017 11:42


===
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Mirrors Team 

If you wish to submit further information on this problem, please
send it to 869...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
869878: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869878
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bastian Blank (Client) Posted On: 08 August 2017 11:39



===
Hi

On Tue, Aug 08, 2017 at 11:20:38AM +0200, CDN77.com - Tech wrote:
> we know about the recommendation to not to sync directly from debian 
> (ftp..debian.org) sites, but now we need to be sure that the archive is 
> up to date. We are picking another mirrors which will meet our needs. 

Just select the names backing this services:

> > Archive-upstream: ftp.nl.debian.org
> > CDImage-upstream: ftp2.de.debian.org

ftp2.de.debian.org. 600 IN  CNAME ftp.halifax.rwth-aachen.de.

> Our archive is already synced four times a day to match twice a day update 
> frequency.

Well, you submission said "twice".

> Did you find any other problem with our archive ?

I don't think so.

Bastian

-- 
Sometimes a feeling is all we humans have to go on.
-- Kirk, "A Taste of Armageddon", stardate 3193.9




Jaroslav Shejbal Posted On: 08 August 2017 11:20


===
Hi Bastian,

we know about the recommendation to not to sync directly from debian 
(ftp..debian.org) sites, but now we need to be sure that the archive is up 
to date. We are picking another mirrors which will meet our needs. 

Our archive is already synced four times a day to match twice a day update 
frequency.

Did you find any other problem with our archive ?

Regards,
Jaroslav

-- 
Best Regards,
Jaroslav ShejbalCDN77.com | Content Delivery Network
m: t...@cdn77.com | sa...@cdn77.com
t: +1-718-427-9911 (US)
t: +44 (0) 20 3514 2399 (UK)
w: http://www.cdn77.com


Bastian Blank (Client) Posted On: 04 August 2017 13:51



===
Control: retitle -1 mirror submission for mirror.nl.10gbps.io 
[upstream-round-robin update-frequency]
Control: tags -1 moreinfo

Hi Tomas

Thank you for mirroring Debian.

We recommend mirrors not sync directly from service aliases such as
ftp..debian.org (only http is guaranteed to be available at
ftp..d.o sites).  Maybe change your config to sync from a specific
site.

Please update four times a day to match the archive update frequency.

Regards,
Bastian

On Thu, Jul 27, 2017 at 11:17:31AM +, Tomas Sykora wrote:
> Submission-Type: new
> Site: mirror.nl.10gbps.io
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> CDImage-http: /debian-cd/
> Archive-upstream: ftp.nl.debian.org
> CDImage-upstream: ftp2.de.debian.org
> Updates: twice

-- 
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1






Ticket Details
-
Ticket ID: 476427
Department: CDN77 - tech (internal)
Type: Issue
Status: Closed
Priority: Low

Helpdesk: https://podpora.superhosting.cz/index.php?

Bug#871282: insighttoolkit4.10: requires rebuild against GCC 7 and symbols/shlibs bump

[Gert Wollny]

Control: tags -1 wontfix 

Version 4.12 is in unstable, was already build using gcc-7, and will
soon transition to testing thereby removing v4.10 from the archives. 

Best, 
Gert 

Bug#871573: insighttoolkit4 fails to build from source

[Matthias Klose]

Package: src:insighttoolkit4
Version: 4.12.0-dfsg1-1
Severity: serious
Tags: sid buster

[...]
[ 55%] Generating ../../itkFixedArray.xml
cd
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/BUILD/Wrapping/Modules/ITKCommon
&& /usr/bin/castxml -o
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/BUILD/Wrapping/itkFixedArray.xml
--castxml-gccxml --castxml-start _wrapping_ --castxml-cc-gnu "(" /usr/bin/c++ -g
-O2 -fdebug-prefix-map=/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -I/usr/include/nifti -Wall -Wcast-align
-Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral
-Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time
-Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual
-Wstrict-null-sentinel ")" -w -c
@/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/BUILD/Wrapping/ITKCommon.castxml.inc
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/BUILD/Wrapping/itkFixedArray.cxx
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/BUILD/Wrapping/itkFixedArray.cxx:1:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkCommand.h:21:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkObject.h:31:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkLightObject.h:21:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkMacro.h:47:
In file included from /usr/include/c++/7/string:52:
In file included from /usr/include/c++/7/bits/basic_string.h:6159:
In file included from /usr/include/c++/7/ext/string_conversions.h:41:
In file included from /usr/include/c++/7/cstdlib:77:
/usr/include/c++/7/bits/std_abs.h:103:16: error: invalid operands to binary
expression ('__castxml__float128' (aka '__castxml__float128_s') and 'int')
  { return __x < 0 ? -__x : __x; }
   ~~~ ^ ~
/usr/include/c++/7/bits/stl_pair.h:449:5: note: candidate template ignored:
could not match 'pair' against
'__castxml__float128_s'
operator<(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
^
/usr/include/c++/7/bits/stl_iterator.h:305:5: note: candidate template ignored:
could not match 'reverse_iterator' against
'__castxml__float128_s'
operator<(const reverse_iterator<_Iterator>& __x,
^
/usr/include/c++/7/bits/stl_iterator.h:343:5: note: candidate template ignored:
could not match 'reverse_iterator' against
'__castxml__float128_s'
operator<(const reverse_iterator<_IteratorL>& __x,
^
/usr/include/c++/7/bits/stl_iterator.h:1142:5: note: candidate template ignored:
could not match 'move_iterator' against 
'__castxml__float128_s'
operator<(const move_iterator<_IteratorL>& __x,
^
/usr/include/c++/7/bits/stl_iterator.h:1148:5: note: candidate template ignored:
could not match 'move_iterator' against 
'__castxml__float128_s'
operator<(const move_iterator<_Iterator>& __x,
^
/usr/include/c++/7/bits/basic_string.h:5892:5: note: candidate template ignored:
could not match 'basic_string' against '__castxml__float128_s'
operator<(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
^
/usr/include/c++/7/bits/basic_string.h:5905:5: note: candidate template ignored:
could not match 'basic_string' against '__castxml__float128_s'
operator<(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
^
/usr/include/c++/7/bits/basic_string.h:5917:5: note: candidate template ignored:
could not match 'const _CharT *' against '__castxml__float128' (aka
'__castxml__float128_s')
operator<(const _CharT* __lhs,
^
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/BUILD/Wrapping/itkFixedArray.cxx:1:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkCommand.h:21:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkObject.h:31:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkLightObject.h:21:
In file included from
/home/packages/tmp/insighttoolkit4-4.12.0-dfsg1/Modules/Core/Common/include/itkMacro.h:47:
In file included from /usr/include/c++/7/string:52:
In file included from /usr/include/c++/7/bits/basic_string.h:6159:
In file included from /usr/include/c++/7/ext/string_conversions.h:41:
In file included from /usr/include/c++/7/cstdlib:77:
/usr/include/c++/7/bits/std_abs.h:103:22: error: invalid argument type
'__castxml__float128' (aka '__castxml__float128_s') to unary expression
  { return __x < 0 ? -__x : __x; }
 ^~~~
/usr/include/c++/7/bits/std_abs.h:102:3: error: no return statement in constexpr
function
  abs(__float128 __x)
  ^
3 errors generated.
Wrapping/Modules/ITKCommon/CMakeFiles/ITKCommonCastXML.dir/build.make:145:
recipe for target 'Wrapping/itkFixedArray.xml' fail

Bug#871572: urweb FTBFS with gcc 7 on arm64 and mips64el: test failure

[Adrian Bunk]

Source: urweb
Version: 20170720+dfsg-1
Severity: serious

https://tests.reproducible-builds.org/debian/history/urweb.html
https://buildd.debian.org/status/package.php?p=urweb&suite=sid

...
   dh_auto_test -a -O--parallel
make -j6 test VERBOSE=1
make[1]: Entering directory '/<>/urweb-20170720+dfsg'
bin/urweb -boot -noEmacs -dbms sqlite -db /tmp/urweb.db -demo /Demo demo
Unresolved constraint in top.ur
loc: 
/<>/urweb-20170720+dfsg/lib/ur/top.ur:391:4-391:12
 c1:  
 c2:  [#B = ()]
unhandled exception: Fail: Unresolved constraint in top.ur
Makefile:935: recipe for target 'test' failed
make[1]: *** [test] Error 1

Bug#792198: lintian: warn against wrongly named override files

[Chris Lamb]

tags 792198 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=47a6f14e2c506551971291b75a43c4b6c0ed0066


Regards,

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

Bug#871574: ltrace: Please build for mips64el

[intrigeri]

Source: ltrace
Severity: wishlist
Version: 0.7.3-6

Hi,

while debugging a FTBFS on mips64el, upstream asked me to provide the
ltrace output. Sadly, we don't build ltrace for mips64el. Any reason
why we don't?

Thanks!

Cheers,
-- 
intrigeri

Bug#869414: package smplayer/16.11.0~ds0-1+deb9u1

[Gianfranco Costamagna]

>What about #870233, sounds like a good opportunity to fix that along?


it was really too late for that one :)

Mateusz, can you please prepare an update in case you want it fixed?

G.

Bug#871548: Cannot open links in evince (PDF) when chromium is default browser

[intrigeri]

Control: fixed -1 2.11.0-9

Hi!

Phil Wyett:
> Cannot open links via evince (PDF) when chromium is default browser.

Thank you for this report. This was reported (outside of the BTS)
against testing/sid a few days ago, and I believe I've fixed it in sid
in 2.11.0-9.

I intend to propose an update to fix this, and a number of other
AppArmor policy issues, in Stretch. The case for this update will be
easier to make if you test on Stretch the exact diff applied between
2.11.0-8 and 2.11.0-9. Can you please do this? :)

Cheers,
-- 
intrigeri

Bug#871575: lintian: maintainer-address-causes-mail-loops-or-bounces should be fixed to allow @packages.debian.org emails

[Raphaël Hertzog]

Package: lintian
Version: 2.5.51
Severity: normal

I believe that the check maintainer-address-causes-mail-loops-or-bounces
should no longer refuse "*@packages.debian.org" in the Maintainer field.

I did patch the code generating the aliases on packages.debian.org to
avoid mail loops:
https://anonscm.debian.org/cgit/webwml/packages.git/commit/?h=debian-master&id=5f4f27920e996e521d32dfb5a9693a09348d18d5

The current downsides of using such emails is:
- it might generate bounces for ftp-masters for the first emails
  until the package has been accepted in unstable
- Package Tracker subscribers will get duplicate emails from
  various services

Those downsides will need to be fixed but in the mean time I would
like the requirement to be relaxed so that we can try on a test package
and see what services are generating duplicate emails.

Cheers,

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

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

Versions of packages lintian depends on:
ii  binutils  2.28-6
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.18.24
ii  file  1:5.30-1
ii  gettext   0.19.8.1-2+b1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-7
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-7
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b2

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Raphael Hertzog]

Hello,

On Fri, 04 Aug 2017, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

Yes, that's entirely in the scope that I intended to give to
tracker.debian.org. As Paul already pointed out, I started a
DEP on this a long time ago (altough it's broader in scope):
http://dep.debian.net/deps/dep2/

> For legacy purposes, the Maintainer field would then list ${source}@tra
> cker.d.o and the Uploaders field could be removed.

While storing the maintainer information in tracker is far from being
done, I actually worked on various steps to make it possible to have
a generic maintainer address like "@packages.debian.org" (like I
ensured that the packages.debian.org email aliases do not include
packages.debian.org email addresses to avoid loops [1]).

I think the only missing step is some sort of logic to drop duplicate
emails that we would currently get through the tracker if we do not change
anything in dak or the BTS or other scripts that are currently mailing
both the maintainer and the tracker directly.

In the future, I would like to be able to also use “team+...@tracker.debian.org“
so that it's automatically tagged as being part of the corresponding team
and so that the associated mails are sent to the team subscribers. But
here again we have quite some work to do.

FWIW, I just tried to use z...@packages.debian.org as maintainer for my zim
package, we will see if my analysis is right and if I only get a few
duplicates. We will have to fix lintian too because I just see this:

E: zim source: maintainer-address-causes-mail-loops-or-bounces Zim Package 
Maintainers 

And the tag is not overridable and it's fatal for dak. Ansgar, do you
feel like disabling that auto-reject tag temporarily so that I can upload my
test package ?

Cheers,

[1] 
https://anonscm.debian.org/cgit/webwml/packages.git/commit/?h=debian-master&id=5f4f27920e996e521d32dfb5a9693a09348d18d5
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868678: autopkgtest: Support Kali in setup-testbed

[Paul Gevers]

Just to note, I am working on using the requested feature from bug
851568, which makes all this more controllable and flexible. It's needed
for autopkgtesting like Ubuntu does.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#867088: gucharmap build-depends on unicode-data (< 9.1) but 10.0.0-1 is to be installed

[Jeremy Bicha]

Control: tags -1 +pending

This bug is fixed in gucharmap 10. The update was ready a month ago; I
just need a sponsor.

It's in pkg-gnome svn.

Thanks,
Jeremy Bicha

Bug#869658: linux: system freezes when dell-smm-hwmon reads fan speed

[Carmelo C]

Package: linux-image-4.9.0-3-686-pae
Version: 4.9.30-2+deb9u3
Severity: important
Justification: linux: Debian system freezes when dell-smm-hwmon reads fan
speed

I runned the following commands, and attach their outputs:

strace -o strace_hwmon_fan1_output.txt -tt cat
/sys/class/hwmon/hwmon2/fan1_input

strace -o strace_hwmon_fan2_output.txt -tt cat
/sys/class/hwmon/hwmon2/fan2_input

strace -o strace_hwmon_fan3_output.txt -tt cat
/sys/class/hwmon/hwmon2/fan3_input

The execution times of these commands are:

fan1: 1,931609 seconds
fan2: 1,92 seconds
fan3: 1,930267 seconds

In these intervals, the temporary freeze of the Debian operating system
occurs

Bug#869658: linux: system freezes when dell-smm-hwmon reads fan speed

[Carmelo C]

Here are the attachments, which I forgot to send in the previous email...
14:53:33.184354 execve("/bin/cat", ["cat", 
"/sys/class/hwmon/hwmon2/fan1_inp"...], [/* 43 vars */]) = 0
14:53:33.185278 brk(NULL)   = 0x8059b000
14:53:33.185442 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:53:33.185579 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77d
14:53:33.185718 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
14:53:33.185847 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
14:53:33.185974 fstat64(3, {st_mode=S_IFREG|0644, st_size=88243, ...}) = 0
14:53:33.186155 mmap2(NULL, 88243, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77ba000
14:53:33.186270 close(3)= 0
14:53:33.186388 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:53:33.186538 open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
14:53:33.186669 read(3, 
"\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\203\1\0004\0\0\0"..., 512) 
= 512
14:53:33.186789 fstat64(3, {st_mode=S_IFREG|0755, st_size=1791908, ...}) = 0
14:53:33.186907 mmap2(NULL, 1800732, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7602000
14:53:33.187023 mprotect(0xb77b3000, 4096, PROT_NONE) = 0
14:53:33.187139 mmap2(0xb77b4000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b1000) = 0xb77b4000
14:53:33.187289 mmap2(0xb77b7000, 10780, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77b7000
14:53:33.187432 close(3)= 0
14:53:33.187593 set_thread_area({entry_number:-1, base_addr:0xb77d2800, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}) = 0 (entry_number:6)
14:53:33.187894 mprotect(0xb77b4000, 8192, PROT_READ) = 0
14:53:33.188110 mprotect(0x8000e000, 4096, PROT_READ) = 0
14:53:33.188243 mprotect(0xb77fa000, 4096, PROT_READ) = 0
14:53:33.188368 munmap(0xb77ba000, 88243) = 0
14:53:33.188750 brk(NULL)   = 0x8059b000
14:53:33.188867 brk(0x805bc000) = 0x805bc000
14:53:33.189003 open("/usr/lib/locale/locale-archive", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
14:53:33.189161 fstat64(3, {st_mode=S_IFREG|0644, st_size=1679440, ...}) = 0
14:53:33.189294 mmap2(NULL, 1679440, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7467000
14:53:33.189439 close(3)= 0
14:53:33.189662 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), 
...}) = 0
14:53:33.189795 open("/sys/class/hwmon/hwmon2/fan1_input", 
O_RDONLY|O_LARGEFILE) = 3
14:53:33.189965 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
14:53:33.190136 fadvise64_64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
14:53:33.190261 mmap2(NULL, 139264, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7445000
14:53:33.190385 read(3, "2837\n", 131072) = 5
14:53:35.115446 write(1, "2837\n", 5)   = 5
14:53:35.115603 read(3, "", 131072) = 0
14:53:35.115649 munmap(0xb7445000, 139264) = 0
14:53:35.115697 close(3)= 0
14:53:35.115747 close(1)= 0
14:53:35.115784 close(2)= 0
14:53:35.115827 exit_group(0)   = ?
14:53:35.115963 +++ exited with 0 +++
14:53:47.963322 execve("/bin/cat", ["cat", 
"/sys/class/hwmon/hwmon2/fan2_inp"...], [/* 43 vars */]) = 0
14:53:47.964377 brk(NULL)   = 0x80209000
14:53:47.964555 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:53:47.964697 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ac000
14:53:47.964831 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
14:53:47.964960 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
14:53:47.965090 fstat64(3, {st_mode=S_IFREG|0644, st_size=88243, ...}) = 0
14:53:47.965208 mmap2(NULL, 88243, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7796000
14:53:47.965320 close(3)= 0
14:53:47.965435 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
14:53:47.965577 open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
14:53:47.965705 read(3, 
"\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\203\1\0004\0\0\0"..., 512) 
= 512
14:53:47.965825 fstat64(3, {st_mode=S_IFREG|0755, st_size=1791908, ...}) = 0
14:53:47.965943 mmap2(NULL, 1800732, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75de000
14:53:47.966108 mprotect(0xb778f000, 4096, PROT_NONE) = 0
14:53:47.966227 mmap2(0xb779, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b1000) = 0xb779
14:53:47.966381 mmap2(0xb7793000, 10780, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7793000
14:53:47.966525 close(3)= 0
14:53:47.966685 set_thread_area({entry_number:-1, base_addr:0xb77ae800, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}) = 0 (entry_number:6)
14:53:47.966955 mprotect(0xb779, 8192, P

Bug#858890: gnat-6: missing dependency on the gcc package ?

[Nicolas Boulenguez]

Package: gnat
Followup-For: Bug #858890
Control: reassign -1 gnat-6 6.3.0-10
Control: fixed-1 gnat-6 6.4.0-3

Hello.

The "gnat" metapackage only exists to enforce installation of
"gnat-${gnat_version}", via a Depends relationship.

The "gnat-${gnat_version}" package actually installs
/usr/bin/gnatmake-${gnat_version}  (executable calling gcc-{gnat_version})
/usr/bin/gnatmake  -> gnatmake-${gnat_version}
/usr/bin/gnatgcc   -> gcc-${gnat_version}
All this implies that gnat-${gnat_version} Depends: gcc-${gnat_version}.

The gcc package is completely unrelated. It installs
/usr/bin/gcc   ->  gcc-${gcc_version}
which may diff from ${gnat_version} for various reasons.

So "gnat" has good reasons not to depend on gcc or gcc-${gcc_version},
and has no reason to directly Depend: gcc-${gnat_version}.

However, "gnatmake" should by default compile and link with
"gcc-${gnat_version}" so you are describing a concrete problem in the
"gnatmake-6/6.3.0-10" package.

I cannot reproduce this problem with gnat-6/6.4.0-3 (and without gcc).
# gnatmake foo.adb
gcc-6 -c foo.adb
gnatbind-6 -x foo.ali
gnatlink-6 foo.ali
The changes in 6.3.0-18 have probably fixed this issue.

For the record, I cannot reproduce either with gnat-7/7.1.0-12.

Bug#871269: missing Replaces

[Andreas Beckmann]

Followup-For: Bug #871269

Hi Dirk,

for libgslcblas0 the Replaces on libgsl23 needs to be versioned (<< 2.4+dfsg-4).
All the Conflicts can probably be turned into Breaks (which will make apt's life
easier for distupgrades involving this transition) and Breaks and Replaces
need to match w.r.t. to the versioning (otherwise you might run into
weird corner cases).


Andreas

Bug#871576: cinnamon-screensaver-x-plugin: fails to upgrade from 'sid' - trying to overwrite /usr/lib/x86_64-linux-gnu/cinnamon-screensaver/cinnamon-screensaver-dialog

[Andreas Beckmann]

Package: cinnamon-screensaver-x-plugin
Version: 3.4.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package cinnamon-screensaver-x-plugin.
  Preparing to unpack .../181-cinnamon-screensaver-x-plugin_3.4.1-1_all.deb ...
  Unpacking cinnamon-screensaver-x-plugin (3.4.1-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-1LDY9X/181-cinnamon-screensaver-x-plugin_3.4.1-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/cinnamon-screensaver/cinnamon-screensaver-dialog', 
which is also in package cinnamon-screensaver 3.2.13-4
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-1LDY9X/181-cinnamon-screensaver-x-plugin_3.4.1-1_all.deb


cheers,

Andreas


cinnamon-screensaver-x-plugin=3.4.1-1_cinnamon-screensaver=3.4.1-1.log.gz
Description: application/gzip

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

[Jose Gutierrez de la Concha]

Hi James

On Tue, Aug 8, 2017 at 6:07 PM, James Cowgill  wrote:

> On 08/08/17 11:29, Jose Gutierrez de la Concha wrote:
> > On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill  > > wrote:
> > [...]
> > > - If your package does not provide a symbols file, add a
> dh_makeshlibs
> > >   override so that tight enough dependencies are generated.
> > >
> > >   Using libebml as an example (debian/rules):
> > >   + override_dh_makeshlibs:
> > >   + # For new symbols when compiled with GCC 7
> > >   + dh_makeshlibs -V'libebml4v5 (>= 1.3.4-2~)'
> > >
>

Any ideas how should I handle multiple packages in override_dh_makeshlibs
zeroc-ice has several packages that include libzeroc-ice3.6,
libzeroc-freeze3.6
so I cannot really pass a single package name in -V

> > Does this work with dbgsym generated packages?
> >
> > dh_makeshlibs has nothing to do with dbgsym packages. I'm not sure I
> > quite understand your question.
> >
> > As far as I can tell libzeroc-ice3.6 currently does not provide a shlibs
> > or symbols
> > file, so I guess we can skip this for now?
>
> It provides an shlibs file:
> $ dpkg-deb -I libzeroc-ice3.6_3.6.3-5_amd64.deb
>  new debian package, version 2.0.
>  size 1905864 bytes: control archive=1639 bytes.
>  728 bytes,18 lines  control
> 1293 bytes,16 lines  md5sums
>  471 bytes,18 lines   *  postinst #!/bin/sh
>  273 bytes,16 lines   *  postrm   #!/bin/sh
>  398 bytes,12 lines  shlibs
>   60 bytes, 2 lines  triggers
>
> James
>
>

Regards,
José

-- 
José Gutiérrez de la Concha
ZeroC, Inc.

Bug#871577: nano: fails to upgrade from 'testing' - trying to overwrite /usr/share/info/nano.info.gz

[Andreas Beckmann]

Package: nano
Version: 2.8.6-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package nano.
  Preparing to unpack .../nano_2.8.6-2_amd64.deb ...
  Unpacking nano (2.8.6-2) ...
  dpkg: error processing archive /var/cache/apt/archives/nano_2.8.6-2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/share/info/nano.info.gz', which is also in package 
nano-tiny 2.8.6-1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/nano_2.8.6-2_amd64.deb

This bug is the opposite direction of #869876. Since you obviously moved
a file from nano-tiny to nano, you need corresponding versioned Breaks+Replaces.


cheers,

Andreas


nano-tiny=2.8.6-1_nano=2.8.6-2.log.gz
Description: application/gzip

Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests

[Niko Tyni]

On Wed, Aug 09, 2017 at 11:16:03AM +0200, Alex Riesen wrote:
> Package: perl-base
> Version: 5.24.1-3+deb9u1
> Severity: normal

> when I run the test suite (Git (the VCS, master branch), the perl binary
> sometimes crashes in one of its tests. I used the commands below to reproduce
> the problem (just let it run, it'll crash eventually):

Thanks for the thorough report. For now, I'll just note that there's been
somewhat similar bugs in the past on the libsvn-perl (src:subversion)
side that git-svn uses, see at least #780246 and #534763. I don't see
the SVN bindings in your backtrace so it may be something else, but in
that case a test case without SVN in the mix would be good of course.

Anyway, I'll see if I can reproduce this when I find the time.

> I had to recompile the perl package locally to get the details backtrace: I
> failed to find the debug symbols of the perl package here:
> deb http://debug.mirrors.debian.org/debian-debug/ stretch-debug main non-free 
> contrib

They are in the perl-debug package in the main archive, mostly for
historical reasons.
-- 
Niko Tyni   nt...@debian.org

Bug#871578: winff: fails to upgrade from 'testing' - trying to overwrite /usr/share/applications/winff.desktop

[Andreas Beckmann]

Package: winff
Version: 1.5.5-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package winff.
  Preparing to unpack .../202-winff_1.5.5-3_all.deb ...
  Unpacking winff (1.5.5-3) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-Gux07i/202-winff_1.5.5-3_all.deb (--unpack):
   trying to overwrite '/usr/share/applications/winff.desktop', which is also 
in package winff-data 1.5.5-2
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-Gux07i/202-winff_1.5.5-3_all.deb


cheers,

Andreas


winff-data=1.5.5-2_winff=1.5.5-3.log.gz
Description: application/gzip

Bug#811565: [pkg-go] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Shengjing Zhu]

Hi all,

I spent some time playing around GitHub api, and results a small tool,
https://github.com/zhsj/git-watch

I didn't implement it in uscan. But it can work well with uscan.

A demo service is at https://watch.zhsj.me/

Take one of packages I maintained,
https://tracker.debian.org/golang-github-xiaq-persistent
https://watch.zhsj.me/github/xiaq/persistent is the watch url.
And the following d/watch works fine,

version=4
opts="filenamemangle=s%(?:.*?)?([^/]*)\.tar\.gz%golang-github-xiaq-persistent-$1.tar.gz%"
\
  https://watch.zhsj.me/github/xiaq/persistent \
  (?:.*?/)?([^/]*)\.tar\.gz

This tool works both as web service and cli.

I hope you find this tool useful.

Yours,
Shengjing Zhu

Bug#847728: fail2ban: Fail2ban running shorewall instructions before shorewall is started

[Yaroslav Halchenko]

On Tue, 08 Aug 2017, Graham Bosworth wrote:


>### Note that this is from Gentoo, rather than Debian

yeah

>On a Pentium at 200MHz, 

wow!!! do you have a physical beast like that from 90s?

> it seems that it can indeed terminateprematurely.

any chance you could also try 0.9.7 version?  or even better (eventually
we will switch there) 0.10 branch version from github (there was lots of
changed behaviors, hopefully for the best)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#871514: clamav: FTBFS on mips64el

[Aurelien Jarno]

On 2017-08-08 20:41, Sebastian Andrzej Siewior wrote:
> On 2017-08-08 20:34:37 [+0200], To sub...@bugs.debian.org wrote:
> …
> > returned (the important part):
> > |LibClamAV debug: parseEmailBody() rc 1 infect 0
> > |LibClamAV debug: parseEmailBody() returning 3
> …
> > The exp build passed with gcc-6_6.4.0-1 [0]. Is there an easy way to
> > downgrade the compiler on eller/porterbox? Or could a porter double
> > check this please?
> 
> on eller in a buster chroot:
> |LibClamAV debug: parseEmailBody() rc 1 infect 0
> |LibClamAV debug: parseEmailBody() returning 1
> 
> further suggestions?

I got a quick look. It's indeed a regression introduced by GCC 7. It can
be workarounded by building the file with -O0, but already appears with
-O1 optimization.

I got a quick look with gdb and it seems that loading either the rc
(enum) or infect (bool variable to test it against 0, the load is done 
with the ld instruction instead of the lw instruction. It means garbage
from another local variable is loaded into the high 32 bits, which
causes the comparison against 0 to be false instead of true.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#871579: libpython3.5-stdlib: removal of libpython3.5-stdlib makes files disappear from libpython3.5-testsuite

[Andreas Beckmann]

Package: libpython3.5-stdlib
Version: 3.5.4-1~rc1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libpython3.5-testsuite/stretch
  # (1)
  apt-get install libpython3.5-stdlib/buster
  apt-get remove libpython3.5-stdlib
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/lib/python3.5/test/test_support.py

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
and also see the footnote that describes this incorrect behavior
https://www.debian.org/doc/debian-policy/footnotes.html#f53

The libpython3.5-stdlib package has the following relationships with 
libpython3.5-testsuite:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  libpython3.5-testsuite (<< 3.5.4~rc1-1)

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

0m52.2s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/python3.5/test/__pycache__/test_support.cpython-35.pycnot 
owned
  /usr/lib/python3.5/test/test_support.pyowned by: 
libpython3.5-stdlib:amd64

0m52.2s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libpython3.5-testsuite.list not owned


cheers,

Andreas


libpython3.5-testsuite=3.5.3-1_libpython3.5-stdlib=3.5.4-1.log.gz
Description: application/gzip

Bug#871269: missing Replaces

[Dirk Eddelbuettel]

Hi Andreas,

Thanks for the note.

On 9 August 2017 at 15:58, Andreas Beckmann wrote:
| Followup-For: Bug #871269
| 
| Hi Dirk,
| 
| for libgslcblas0 the Replaces on libgsl23 needs to be versioned (<< 
2.4+dfsg-4).

Oh, right.  

| All the Conflicts can probably be turned into Breaks (which will make apt's 
life
| easier for distupgrades involving this transition) and Breaks and Replaces
| need to match w.r.t. to the versioning (otherwise you might run into
| weird corner cases).

Can the Breaks be similarly versioned?  Let me get a versioned Replaces out,
and maybe we can review then?

Thanks so much,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#871269: missing Replaces

[Andreas Beckmann]

On 2017-08-09 16:49, Dirk Eddelbuettel wrote:
> | All the Conflicts can probably be turned into Breaks (which will make apt's 
> life
> | easier for distupgrades involving this transition) and Breaks and Replaces
> | need to match w.r.t. to the versioning (otherwise you might run into
> | weird corner cases).
> 
> Can the Breaks be similarly versioned?  Let me get a versioned Replaces out,
> and maybe we can review then?

Breaks can be versioned in the same way as Conflicts or Replaces (or
nearly anything else).


Andreas

Bug#811565: [pkg-go] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Thanks for sharing your tool!

I also considered implementing such a tool, but ultimately decided against
it for a number of reasons:

1. I think that infrastructure which the pkg-go team critically and very
visibly depends on should eventually be hosted by DSA under debian.org. I
don’t see them hosting this special “workaround” service, when there
already is infrastructure in place to run uscan.

2. I have concerns regarding the scalability of such a service if we
actually adopted this approach: the GitHub quota permits 5000 requests per
hour (when authenticated). This sounds like a lot at first glance, but
consider that we already have 845 Go packages. Your code does 4 requests
per repository (IIUC), so already we are fairly close to reaching the
limit, if we don’t take any precautions.

Most likely, point ② could be addressed with some careful limiting on our
end, and changing the processing model from generating a response upon
end-user request to iterating through all Go packages in Debian and
querying GitHub in a rate-limited fashion. This significantly complicates
the program, though, to the point where we duplicate the logic behind the
Debian Package Tracker. Worse, it introduces accidental complexity, not
inherent complexity :).

Hence, I think extending uscan is a much much more elegant route to achieve
our goal, and I’d like to ask people to hold off providing/using custom
services as a stop-gap measure. Thanks!

On Wed, Aug 9, 2017 at 7:38 AM, Shengjing Zhu  wrote:

> Hi all,
>
> I spent some time playing around GitHub api, and results a small tool,
> https://github.com/zhsj/git-watch
>
> I didn't implement it in uscan. But it can work well with uscan.
>
> A demo service is at https://watch.zhsj.me/
>
> Take one of packages I maintained,
> https://tracker.debian.org/golang-github-xiaq-persistent
> https://watch.zhsj.me/github/xiaq/persistent is the watch url.
> And the following d/watch works fine,
>
> version=4
> opts="filenamemangle=s%(?:.*?)?([^/]*)\.tar\.gz%golang-githu
> b-xiaq-persistent-$1.tar.gz%"
> \
>   https://watch.zhsj.me/github/xiaq/persistent \
>   (?:.*?/)?([^/]*)\.tar\.gz
>
> This tool works both as web service and cli.
>
> I hope you find this tool useful.
>
> Yours,
> Shengjing Zhu
>



-- 
Best regards,
Michael

Bug#871538: Makes apparmor FTBFS on mips64el (generated code thinks that 1 > 1)

[intrigeri]

Hi mips porters,

can you please have a look at #871538? It includes gdb debugging
information that seems to demonstrate a regression in the toolchain on
mips64el with GCC-7.

Cheers,
-- 
intrigeri

Bug#871580: ITP: mediawiki-extensions-translate -- MediaWiki tool for translations

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: mediawiki-extensions-translate
  Version :
  Upstream Author : Niklas Laxström et al.
* URL : https://www.mediawiki.org/wiki/Extension:Translate
* License : GPL
  Programming Lang: PHP
  Description : MediaWiki tool for translations

Translate extension makes MediaWiki a powerful tool to translate every kind of
text. It's used especially to translate software and to manage multilingual
wikis.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#871581: jack-audio-connection-kit: Add build profile annotations to debian/control

[Daniel Schepler]

Source: jack-audio-connection-kit
Version: 1:0.125.0-2
Severity: wishlist

It would be great if the next upload could update the Build-Depends so
that the package could be bootstrapped mechanically.  As far as I
know, it should be enough just to update the Build-Depends with:

Build-Depends: ..., libffado-dev (>= 2.0.0) [linux-any] , ...
-- 
Daniel Schepler

Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1

[Andreas Beckmann]

On Tue, 08 Aug 2017 16:12:47 -0400 "Adam D. Barratt"
 wrote:
> Please go ahead, and we'll hope it looks sane after that. :-p

Uploaded, with the attached diff (from svn, excluding the blobs).

Unfortunately I messed up while syncing the packaging between the driver
series (should only have brought the lintian overrides in sync) and the
stretch upload includes an unused patch from legacy 340xx driver. 375.82
builds for Linux 4.12 out-of-the-box.
Please ignore debian/module/debian/patches/set-memory.patch (it's not
used in series.in). Sorry for that. I only recognized it after uploading
to jessie-backports as well ...


Andreas


ngd_375.66-2~deb9u1_375.82-1~deb9u1.diff.gz
Description: application/gzip

Bug#871548: Cannot open links in evince (PDF) when chromium is default browser

[Phil Wyett]

On Wed, 2017-08-09 at 09:04 -0400, intrigeri wrote:
> Control: fixed -1 2.11.0-9
> 
> Hi!
> 
> Phil Wyett:
> > Cannot open links via evince (PDF) when chromium is default browser.
> 
> Thank you for this report. This was reported (outside of the BTS)
> against testing/sid a few days ago, and I believe I've fixed it in sid
> in 2.11.0-9.
> 
> I intend to propose an update to fix this, and a number of other
> AppArmor policy issues, in Stretch. The case for this update will be
> easier to make if you test on Stretch the exact diff applied between
> 2.11.0-8 and 2.11.0-9. Can you please do this? :)
> 
> Cheers,

Hi,

Ahem... Reported outside BTS. Anything not in BTS, does not exist. ;-)

As requested, but no link supplied to help me. I have tested patch:

https://alioth.debian.org/scm/loggerhead/collab-maint/apparmor/revision/1651

All is good and the issue as reported is fixed when this patch is applied.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Twitter: kathenasorg

Instagram: kathenasorg

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

Bug#871584: atk_text_get_get() return value incorrect after multbyte character

[Raphaël POITEVIN]

Package:  Firefox
Version: 54.0-2
Tags: a11y upstream
Owner: b...@hypra.fr
User: b...@hypra.fr
Usertags: hypra
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1346535

DESCRIPTION FROM UPSTREAM:


"Steps to reproduce:

1. Load data:text/html;charset=utf-8,Hello %F0%9F%92%97 world

2. Use Accerciser to find the accessible object corresponding with the 
 element.


3. In the ipython console, type the following:

-
text = acc.queryText()
allText = text.getText(0,-1)
["%s %s" % (allText[i], text.getText(i, i+1)) for i in 
range(len(allText))]

-

Expected results: The values would match.

Actual results: The values match only until the multibyte character is 
reached. It seems like the get text implementation is assuming 
single-byte chars (see example output below). Also note that 
performing the same test using the Gedit text editor works as expected.


['H H',
 'e e',
 'l l',
 'l l',
 'o o',
 '   ',
 '"

--
Logo Hypra  RAPHAËL POITEVIN
FORMATEUR / AGENT DE SUPPORT
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Dir : +339 72 49 77 48 


rpoite...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra 

Bug#871585: python-apt: FTBFS: Test failure

[Daniel Schepler]

Source: python-apt
Version: 1.4.0~beta3
Severity: serious

>From my pbuilder build log:

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/python-apt-1.4.0~beta3'
set -e; for python in python2.7 python3.6 python3.5 ; do \
   $python tests/test_all.py -q || [ "linux" = "hurd" ]; \
done;
[tests] Running on 2.7.13+ (default, Jul 19 2017, 18:15:03) [GCC 6.4.0 20170704]
Using library_dir:
'/build/python-apt-1.4.0~beta3/build/lib.linux-x86_64-2.7'WARNING:
Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
WARNING: Failed to read mirror file
==
ERROR: testAddKeyFromServer (test_auth.TestAuthKeys)
Install a GnuPG key from a remote server.
--
Traceback (most recent call last):
 File "/build/python-apt-1.4.0~beta3/tests/test_auth.py", line 239, in
testAddKeyFromServer
   "hkp://localhost:%d" % self.keyserver_port)
 File "/build/python-apt-1.4.0~beta3/build/lib.linux-x86_64-2.7/apt/auth.py",
line 137, in add_key_from_keyserver
   shutil.rmtree(tmp_keyring_dir)
 File "/usr/lib/python2.7/shutil.py", line 266, in rmtree
   onerror(os.remove, fullname, sys.exc_info())
 File "/usr/lib/python2.7/shutil.py", line 264, in rmtree
   os.remove(fullname)
OSError: [Errno 2] No such file or directory: '/tmp/tmpVdpO4x/S.gpg-agent.extra'

--
Ran 97 tests in 21.771s

FAILED (errors=1, skipped=2)
debian/rules:50: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/python-apt-1.4.0~beta3'
debian/rules:16: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- 
Daniel Schepler

Bug#871583: firefox-esr: OOOBUpdate to 52.3.0 borks Firefox graphics

[debianuser]

Package: firefox-esr
Version: 52.3.0esr-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
On Debian Sid, did an apt upgrade (no packages were held back so a dist-upgrade 
was not necessary) and updated Firefox from 52.2.0 to 52.3.0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Attempted to start in safe mode and the problem persisted  

 


-- Package-specific info:

-- Extensions information
Name: Application Update Service Helper
Location: ${PROFILE_EXTENSIONS}/aushel...@mozilla.org.xpi
Status: enabled

Name: Decentraleyes
Location: ${PROFILE_EXTENSIONS}/jid1-bofifl9vbdl...@jetpack.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: user-disabled

Name: F.B Purity - Cleans up Facebook (WX)
Location: ${PROFILE_EXTENSIONS}/fbpelectroweb...@fbpurity.com.xpi
Status: enabled

Name: FrankerFaceZ
Location: ${PROFILE_EXTENSIONS}/jid1-snhdau6px3p...@jetpack.xpi
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org.xpi
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi
Status: enabled

Name: Space Fantasy theme
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: Skype Buttons for Kopete
Location: /usr/lib/mozilla/plugins/skypebuttons.so
Package: kopete
Status: enabled


-- Addons package information
ii  firefox-esr52.3.0esr-1  amd64Mozilla Firefox web browser - Ext
ii  icedtea-8-plug 1.6.2-3.1amd64web browser plugin based on OpenJ
ii  kopete 4:16.08.1-3  amd64instant messaging and chat applic

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.2
ii  fontconfig2.12.3-0.2
ii  libasound21.1.3-5
ii  libatk1.0-0   2.24.0-1
ii  libc6 2.24-14
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libdbus-1-3   1.11.16+really1.10.22-1
ii  libdbus-glib-1-2  0.108-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-6
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.1.0-13
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.53.4-3
ii  libgtk-3-03.22.17-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.6-0 1.6.1-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.15-1
ii  libnss3   2:3.31-1
ii  libpango-1.0-01.40.6-1
ii  libsqlite3-0  3.19.3-3
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++67.1.0-13
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

firefox-esr recommends no packages.

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15.1-2
pn  mozplugger 

-- no debconf information

Bug#541538: pidgin sound volume / bad interaction with pulseaudio flat-volumes

[Brian Ristuccia]

There is a bad interaction between the manner in which Pidgin sets the 
sound volume and the flat-volumes "feature" in Pulseaudio, whereby the 
master output volume is changed whenever Pidgin adjusts its volume in 
preparation for playing alerts sounds. On my system, the result was that 
the master volume would increase to 100% (and stay that way) whenever 
pidgin played a sound.


One workaround is to prevent Pidgin from trying to change the sound 
volume by setting the sound playback method to "Command" and the command 
to "paplay %s" in the sounds tab of the Pidgin preferences dialog. 
Another fix is to disable flat-volumes in pulseaudio.


See also Debian Bug #541538 against pulseaudio.

-Brian

Bug#871589: fonts-glewlwyd: should use package section fonts

[Jonas Smedegaard]

Package: fonts-glewlwyd
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Font packages should be in package section fonts (not web).

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlmLOQMACgkQLHwxRsGg
ASGYfQ//VpuTARSAN39FpwLPuwvqSmFLxIZ+qOsPgq/osU4p/6fIWunTznrZ9+Zl
Ny+9iXP0R5/WiBo2ySK0DsCjlFiQyKOnyqbHxUYNSaUs+fjthKMiA5zLPxE9s7SL
bXvxVEDmWgkYXxBpb8iLOt40lnXYE/4TlQw1erYno0zyH6unNjmggPrRDJNRthNc
l9bqx4PHYIXQ/Aa9K99MJ3+Ns4kD8h/XZYlDi0t4hrVCBWxwehJz7Ulauf55VNsA
TLjbDBOKK4LXCsgUguwfydw3TKT/Eb09cGb0c+M0gw6w1iM3dOXtkDrvCchhD+Be
dD5OqWzKwfyLgZkzqS3Y4DoPeywAnrmiCaumJGYdwE8oGRga8sIbM8n4Ypb1H1dO
OL9aR4si6QO/ON2PIhxdfJRycC+AlcJCZi76+pGE+XDTdUz9J8P2KSKasLBDi0RU
uo/c2dH2EWmODgi9SPpPjtWe3jMW72VotQ06B/GVwO5KFd2ANLMeLVN9cvssfT+x
VD0Lwz7X/BL1/3FpFJ/p2NP0Ypxm/CF+A0NlcGMgDWQ3H/d188ICh28U5hQOKf5y
CBUArSRU7huD3mRjTn7yKCJ3/+aqTAigUOl6WsClxS7d1yVx3Q2aExvQbrYvNZTW
2DtHgqB1UkgRlO66xh68tv51nI+bzcVDqNGIerB5szciFx83vZ8=
=YC86
-END PGP SIGNATURE-

Bug#811565: [pkg-go] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Shengjing Zhu]

Thanks for the comment.

On Wed, Aug 9, 2017 at 10:54 PM, Michael Stapelberg
 wrote:
> 1. I think that infrastructure which the pkg-go team critically and very
> visibly depends on should eventually be hosted by DSA under debian.org. I
> don’t see them hosting this special “workaround” service, when there already
> is infrastructure in place to run uscan.

Well it can be hosted by DSA, or even don't use web service. Maybe
uscan can just call its cli tool.
I do hope someone can implement it in perl and bring it to uscan. But
it's hard for me to hack 4k lines perl.

Anyway, it's an exploration for using API rather than `git clone` locally.
And I intend to get it to support more Git services, maybe gopkg.in,
gitlab, etc.

PS, gopkg.in will point to some specific branch, and
github.com///tags doesn't work well even I append a
'?after=' suffix.


>
> 2. I have concerns regarding the scalability of such a service if we
> actually adopted this approach: the GitHub quota permits 5000 requests per
> hour (when authenticated). This sounds like a lot at first glance, but
> consider that we already have 845 Go packages. Your code does 4 requests per
> repository (IIUC), so already we are fairly close to reaching the limit, if
> we don’t take any precautions.

I haven't considered rate-limit, but do we check so frequently indeed?


-- 
Best regards,
Shengjing Zhu

Bug#871588: libreoffice-calc: Middle button paste does not work

[Kamil Jonca]

Package: libreoffice-calc
Version: 1:5.4.0-1
Severity: normal

1. Open Writer or Calc window 
2. Open emacs or xterm  window,  write some random text.
3.Select this text (but DON'T use Ctrl-Insert or sth)
4. change focus to Calc or Writer window
5. push middle mouse button

I expect, that in libreoffice window should paste text I selected earlier.
This work in 1:5.2.7-1 and previous versions


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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3   2.8.12-1+b2
ii  coinor-libcoinmp1v5  1.7.6+dfsg1-2
ii  coinor-libcoinutils3v5   2.9.15-4
ii  libblas3 [libblas.so.3]  3.7.1-1
ii  libboost-filesystem1.62.01.62.0+dfsg-4+b1
ii  libboost-iostreams1.62.0 1.62.0+dfsg-4+b1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-14
ii  libetonyek-0.1-1 0.1.6-5
ii  libgcc1  1:7.1.0-13
ii  libicu57 57.1-6
ii  liblapack3 [liblapack.so.3]  3.7.1-1
ii  liblcms2-2   2.8-4
ii  libmwaw-0.3-30.3.12-1
ii  libodfgen-0.1-1  0.1.6-2
ii  liborcus-0.12-0  0.12.1-3
ii  libreoffice-base-core1:5.4.0-1
ii  libreoffice-core 1:5.4.0-1
ii  librevenge-0.0-0 0.0.4-6
ii  libstaroffice-0.0-0  0.0.4-1
ii  libstdc++6   7.1.0-13
ii  libwps-0.4-4 0.4.7-1
ii  libxml2  2.9.4+dfsg1-3
ii  lp-solve 5.5.0.15-4+b1
ii  uno-libs35.4.0-1
ii  ure  5.4.0-1
ii  zlib1g   1:1.2.8.dfsg-5

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
pn  ocl-icd-libopencl1  

Versions of packages libreoffice-core depends on:
ii  fontconfig2.12.3-0.2
ii  fonts-opensymbol  2:102.10+LibO5.4.0-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4+b1
ii  libc6 2.24-14
ii  libcairo2 1.14.10-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.4-3
ii  libcurl3-gnutls   7.52.1-5
ii  libdbus-1-3   1.11.16+really1.10.22-1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libepoxy0 1.3.1-3
ii  libexpat1 2.2.3-1
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libgcc1   1:7.1.0-13
ii  libglib2.0-0  2.53.4-3
ii  libgltf-0.1-1 0.1.0-2
ii  libgpgmepp6   1.8.0-3+b3
ii  libgraphite2-31.3.10-2
ii  libharfbuzz-icu0  1.4.2-1
ii  libharfbuzz0b 1.4.2-1
ii  libhunspell-1.6-0 1.6.1-2
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-6
ii  libjpeg62-turbo   1:1.5.1-2
ii  liblcms2-22.8-4
ii  libldap-2.4-2 2.4.45+dfsg-1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.15-1
ii  libnss3   2:3.31-1
ii  libodfgen-0.1-1   0.1.6-2
ii  liborcus-0.12-0   0.12.1-3
ii  libpcre3  2:8.39-4
ii  libpng16-16   1.6.31-1
ii  libpoppler64  0.48.0-2
ii  librdf0   1.0.17-1.1
ii  libreoffice-common1:5.4.0-1
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b3
ii  libstdc++67.1.0-13
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-3
ii  libxmlsec11.2.24-4
ii  libxmlsec1-nss1.2.24-4
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-2.1
ii  uno-libs3 5.4.0-1
ii  ure   5.4.0-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.24+nmu5

-- no debconf information

Bug#868561: knot-resolver 1.2.0-1 occasionally fails to reply correctly to DS queries

[Vladimír Čunát]

Hello!

Note: this problem should be fixed upstream since 1.2.2.

--Vladimir

Bug#852436: cups-browsed uses 100% CPU - SOLVED (patch attached)

[Cédric Dufour - Idiap Research Institute]

On 09/08/17 10:02, Cédric Dufour - Idiap Research Institute wrote:
> I confirm this issue is still present is current Debian Stable/Stretch and 
> renders CUPS unusable in network printing environments.
> I could backport the packages from testing or experimental, but then I would 
> miss the updates from the Debian Security team (and looking at the updates 
> history of CUPS filters/browsed in Debian OldStable/Jessie, it is not 
> something I'm looking forwards to)

I tracked down the issue to a timeout when 'cups-browsed' interacts with the 
local 'cups' server ("cupsDoFileRequest" call).
The 'cups-browsed' hard-coded timeout for such operations is 3 seconds.
This timeout is the cause of the witnessed "Unable to create/modify CUPS queue 
(Success)!" error messages (and 'cups-browsed' looping infinitely in attempts 
to add the failing printers/queues)

For large (fancy ?) PPDs, the local 'cups' server can take up to 8 (!) seconds 
to process the addition of a remote printer queue based on the PPD retrieved 
from the (BrowsePoll-ed) server (as witnessed on a 3.4GHz Intel I7-2600K test 
host, during wich one CPU core is stuck at 100%).

The attached patch file - for cups-filters 1.11.6 (Debian/Stretch) - allows one 
to configure the timeouts of both local and remote 'cups-browsed' HTTP 
connections, thanks to the new "HttpLocalTimeout" and "HttpRemoteTimeout" 
configuration settings. Setting the former to 10 seconds fixed the issue with 
my troublesome PPDs/printers (INEO+ copiers).

Please note that this issue will still be present in 'cups-browsed' 1.16.0 
along 'cups' 2.2.4, as backported from Testing and *verified* on Stretch.
(it should not be difficult to forward-port the attached patch, however)

I hope this patch can meet your approval for its addition in Debian patches 
series and considered even for current Stable release (knowing that enterprise 
environments with big printing beasts will be bound to stumble on the same 
problem).
And do you have a privileged contact to propose this patch be included upstream 
?

Best,

Cédric

diff -urN cups-filters-1.11.6.orig/utils/cups-browsed.c cups-filters-1.11.6/utils/cups-browsed.c
--- cups-filters-1.11.6.orig/utils/cups-browsed.c	2017-08-09 16:48:36.0 +0200
+++ cups-filters-1.11.6/utils/cups-browsed.c	2017-08-09 17:01:05.609442696 +0200
@@ -339,6 +339,8 @@
 static guint update_netifs_sourceid = 0;
 static char local_server_str[1024];
 static char *DomainSocket = NULL;
+static unsigned int HttpLocalTimeout = 5;
+static unsigned int HttpRemoteTimeout = 10;
 static ip_based_uris_t IPBasedDeviceURIs = IP_BASED_URIS_NO;
 static unsigned int CreateRemoteRawPrinterQueues = 0;
 static unsigned int CreateIPPPrinterQueues = 0;
@@ -579,6 +581,7 @@
 int
 http_timeout_cb(http_t *http, void *user_data)
 {
+  debug_printf("HTTP timeout! (consider increasing HttpLocalTimeout/HttpRemoteTimeout value)\n");
   return 0;
 }
 
@@ -591,7 +594,7 @@
 		cupsEncryption());
   }
   if (local_conn)
-httpSetTimeout(local_conn, 3, http_timeout_cb, NULL);
+httpSetTimeout(local_conn, HttpLocalTimeout, http_timeout_cb, NULL);
   else
 debug_printf("cups-browsed: Failed creating http connection to local CUPS daemon: %s:%d\n", cupsServer(), ippPort());
 
@@ -2617,7 +2620,7 @@
 		   p->port);
 	  if (http) {
 	/* Check whether the printer is idle, processing, or disabled */
-	httpSetTimeout(http, 2, http_timeout_cb, NULL);
+	httpSetTimeout(http, HttpRemoteTimeout, http_timeout_cb, NULL);
 	request = ippNewRequest(CUPS_GET_PRINTERS);
 	ippAddStrings(request, IPP_TAG_OPERATION, IPP_TAG_KEYWORD,
 			  "requested-attributes",
@@ -3576,7 +3579,7 @@
 	p->timeout = current_time + TIMEOUT_RETRY;
 	break;
   }
-  httpSetTimeout(http, 3, http_timeout_cb, NULL);
+  httpSetTimeout(http, HttpLocalTimeout, http_timeout_cb, NULL);
 
   /* Do not auto-save option settings due to the print queue creation
 	 process */
@@ -3629,7 +3632,7 @@
 	p->no_autosave = 0;
 	break;
 	  }
-	  httpSetTimeout(remote_http, 3, http_timeout_cb, NULL);
+	  httpSetTimeout(remote_http, HttpRemoteTimeout, http_timeout_cb, NULL);
 	  if ((loadedppd = cupsGetPPD2(remote_http, p->name)) == NULL &&
 	  CreateRemoteRawPrinterQueues == 0) {
 	debug_printf("Unable to load PPD file for %s from the server %s:%d!\n",
@@ -5631,7 +5634,7 @@
 return;
   }
 
-  httpSetTimeout(conn, 3, http_timeout_cb, NULL);
+  httpSetTimeout(conn, HttpRemoteTimeout, http_timeout_cb, NULL);
 
   debug_printf ("cups-browsed [BrowsePoll %s:%d]: IPP-Cancel-Subscription\n",
 		context->server, context->port);
@@ -5772,7 +5775,7 @@
 goto fail;
   }
 
-  httpSetTimeout(conn, 3, http_timeout_cb, NULL);
+  httpSetTimeout(conn, HttpRemoteTimeout, http_timeout_cb, NULL);
 
   if (context->can_subscribe) {
 if (context->subscription_id == -1) {
@@ -6288,6 +6291,19 @@
 } else if (!strcasecmp(line, "DomainSocket") && value) {
   if (value[0] != '\0')
 	DomainSocket = strd

Bug#871548: Cannot open links in evince (PDF) when chromium is default browser

[intrigeri]

Phil Wyett:
> As requested, but no link supplied to help me. I have tested patch:
> https://alioth.debian.org/scm/loggerhead/collab-maint/apparmor/revision/1651
> All is good and the issue as reported is fixed when this patch is applied.

Thanks!

Bug#871590: printer-driver-ptouch: QL-550 doesn't print on 62 mm labels

[Lars Wirzenius]

Package: printer-driver-ptouch
Version: 1.4.2-2+b1
Severity: normal

Dear Maintainer,

I have a Brother P-touch QL-550 label printer, and it works just fine
when printing to 12 mm wide labels (from a continuous roll). However,
if I print on 62 mm wide labels (also from continuous roll), the
printer just blinks its LED at 1-2 Hertz.

That's with the 1.4.2-2+b1 version of the package, from stretch.

If I downgrade the package to 1.3-8, printing works for 62 mm wide
labels, and also 12 mm labels. With 1.4-1 printing doesn't work, so it
looks like 1.3-8 from snapshot.debian.net is the newest version that
works.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages printer-driver-ptouch depends on:
ii  ghostscript9.20~dfsg-3.2
ii  libc6  2.24-11+deb9u1
ii  libcups2   2.2.1-8
ii  libcupsimage2  2.2.1-8
ii  python33.5.3-1
ii  xz-utils   5.2.2-1.2+b1

printer-driver-ptouch recommends no packages.

printer-driver-ptouch suggests no packages.

-- no debconf information

Bug#871586: courier FTBFS with libcourier-unicode-dev 2.0-1

[Adrian Bunk]

Source: courier
Version: 0.76.3-5
Severity: serious
Tags: buster sid

https://buildd.debian.org/status/package.php?p=courier&suite=sid

...
rfc2047.c:379:30: error: unknown type name 'unicode_char'
 static int encode_word(const unicode_char *uc,
  ^~~~
rfc2047.c:412:31: error: unknown type name 'unicode_char'
 static int encode_words(const unicode_char *uc,
   ^~~~
rfc2047.c:457:41: error: unknown type name 'unicode_char'
 static int do_encode_words_method(const unicode_char *uc,
 ^~~~
...

Bug#871269: missing Replaces

[Dirk Eddelbuettel]

On 9 August 2017 at 16:55, Andreas Beckmann wrote:
| On 2017-08-09 16:49, Dirk Eddelbuettel wrote:
| > | All the Conflicts can probably be turned into Breaks (which will make 
apt's life
| > | easier for distupgrades involving this transition) and Breaks and Replaces
| > | need to match w.r.t. to the versioning (otherwise you might run into
| > | weird corner cases).
| > 
| > Can the Breaks be similarly versioned?  Let me get a versioned Replaces out,
| > and maybe we can review then?
| 
| Breaks can be versioned in the same way as Conflicts or Replaces (or
| nearly anything else).

Ok.

Uploaded a -6 with the versioned Replaces but just got a note it is in NEW
because of libgsl-prof -- which seems strange.  Any idea?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#871587: maildrop FTBFS with libcourier-unicode-dev 2.0-1

[Adrian Bunk]

Source: maildrop
Version: 2.8.4-2
Severity: serious
Tags: buster sid

https://buildd.debian.org/status/package.php?p=maildrop&suite=sid

...
rfc2047.c:379:30: error: unknown type name 'unicode_char'
 static int encode_word(const unicode_char *uc,
  ^~~~
rfc2047.c:412:31: error: unknown type name 'unicode_char'
 static int encode_words(const unicode_char *uc,
   ^~~~
rfc2047.c:457:41: error: unknown type name 'unicode_char'
 static int do_encode_words_method(const unicode_char *uc,
 ^~~~
...

Bug#870762: filters FTCBFS: strips using the build architecture strip

[Marius Gavrilescu]

Helmut Grohne  writes:

> filters fails to cross build from source, because it strips at
> installation time (via install -s). Since it uses the build architecture
> strip, this breaks cross building and it also breaks -dbgsym packages.
> After removing -s, filters cross builds successfully. Please consider
> applying the attached patch.

Dear Helmut,

I've uploaded filters 2.55-3 to mentors, could you please sponsor it?

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

Thank you,
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#799144: ITP: ansible-lint -- Best practices checker for Ansible

[Gregory Colpart]

any news?

I have a package ready, I intent to take over the ITP if no answer.

Regards,
-- 
Grégory Colpart   GnuPG:4096R/B8612B5D
Evolix - Hébergement et Infogérance Open Source http://www.evolix.fr/

Bug#871591: [src:llvm-toolchain-snapshot] FTBFS: debian/rules fails to detect gcc-7

[Katsuhiko Nishimra]

Package: src:llvm-toolchain-snapshot
Version: 1:5.0~svn305653-1
Severity: serious
Tags: patch sid
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-7

Dear LLVM packagers,

I've noticed that llvm-toolchain-snapshot goes FTBFS because
`debian/rules' in the packge fails to detect gcc-7 (it tries to use
gcc-7.1). The Jenkins builds seem to be failing due to the same bug.
http://llvm-jenkins.debian.net/view/Debian%20unstable/job/llvm-toolchain-binaries/architecture=amd64,distribution=unstable/898/console

Here I send a patch to fix this by ensuring the existence of
/usr/bin/g++-$(GCC_VERSION) on the build system.

Could you take a look at it please?
diff -Nru llvm-toolchain-snapshot-5.0~svn305653/debian/changelog llvm-toolchain-snapshot-5.0~svn305653/debian/changelog
--- llvm-toolchain-snapshot-5.0~svn305653/debian/changelog	2017-06-09 19:04:56.0 +0900
+++ llvm-toolchain-snapshot-5.0~svn305653/debian/changelog	2017-08-09 23:32:40.0 +0900
@@ -1,3 +1,10 @@
+llvm-toolchain-snapshot (1:5.0~svn305653-1.1) UNRELEASED; urgency=medium
+
+  * Ensure /usr/bin/g++-$(GCC_VERSION) exists
+
+ -- Katsuhiko Nishimra   Wed, 09 Aug 2017 23:32:40 +0900
+
 llvm-toolchain-snapshot (1:5.0~svn305653-1) unstable; urgency=medium
 
   [ Gianfranco Costamagna ]
diff -Nru llvm-toolchain-snapshot-5.0~svn305653/debian/rules llvm-toolchain-snapshot-5.0~svn305653/debian/rules
--- llvm-toolchain-snapshot-5.0~svn305653/debian/rules	2017-06-09 19:04:56.0 +0900
+++ llvm-toolchain-snapshot-5.0~svn305653/debian/rules	2017-08-09 23:32:40.0 +0900
@@ -2,9 +2,11 @@
 
 TARGET_BUILD	:= build-llvm
 DEB_INST		:= $(CURDIR)/debian/tmp/
-# The 5|6| in the regexp is a crappy workaround. g++ 5.2 in Debian is not providing a g++-5.2 binary (only g++-5)
-# accomodate that by hardcoding the 5 detection
-GCC_VERSION := $(shell dpkg-query -W -f '$${Version}' g++ | sed -rne 's,^([0-9]+:)?(5|6|[0-9]+\.[0-9]+|[0-9]+).*$$,\2,p')
+
+GXX_VERSIONED_PACKAGE:= $(shell dpkg-query -W -f '$${Depends}' g++ | grep -o 'g++-[0-9][0-9.]*' | tail -n1 )
+GXX_VERSIONED_EXECUTABLE := $(shell dpkg -L $(GXX_VERSIONED_PACKAGE) | grep '/usr/bin/g++-[0-9][0-9.]*' | xargs ls -d | tail -n1 )
+GCC_VERSION  := $(subst /usr/bin/g++-,,$(GXX_VERSIONED_EXECUTABLE))
+
 LLVM_VERSION	:= 5.0
 LLVM_VERSION_FULL := $(LLVM_VERSION).0
 


signature.asc
Description: PGP signature

Bug#724711: insighttoolkit4: Drops architecture support

[Edmund Grimley Evans]

Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64

Please consider adding arm64.

Ubuntu built 4.9.0, 4.10.0 and 4.10.1 on arm64:

http://ports.ubuntu.com/ubuntu-ports/pool/universe/i/insighttoolkit4/

Though it looks like they may have ignored a few test failures to get there:

https://launchpad.net/ubuntu/+source/insighttoolkit4/+changelog

Bug#871592: logrotate does not ever recover from a corrupted statefile

[Eric Desrochers]

Package: logrotate
Version: 3.11.0-0.1
Severity: normal

Dear Maintainer,

logrotate does not ever recover from a corrupted statefile.

Reproducer :
- Install logrotate
- Run by hand "/etc/cron.daily/logrotate"   # The first logrotate run will 
generate the statefile "var/lib/logrotate/status"
- Modify "/var/lib/logrotate/status" by removing the first line in order to 
corrupt the file.
- Re-run "/etc/cron.daily/logrotate" and you will get something like this 
"error: bad top line in state file /var/lib/logrotate/status" every time you 
run logrotate.

logrotate never recovers if the statefile is corrupted unless you remove it or 
fix the corruption by hand.

The following upstream[1] commit introduce in 3.12.0 version is fixing the 
situation[2]

[1] - 
https://github.com/logrotate/logrotate/commit/b9d82003002c98370e4131a7e43c76afcd23306a

# git clone https://github.com/logrotate/logrotate.git
# git describe --contains b9d8200
3.12.0~18

[2] - https://github.com/logrotate/logrotate/issues/45

-- System Information:
Debian Release: 8.7
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Bug#856586: e2fsprogs: gettext ignoring fuzzy translations

[Benedikt Wildenhain (BO)]

Package: e2fsprogs
Version: 1.43.5-1
Tags: patch
Followup-For: Bug #856586

Dear Maintainer,

I saw the same problem, I could fix it by applying the following patch:

--- e2fsprogs-1.43.5-orig/po/de.po  2017-08-04 07:30:21.0 +0200
+++ e2fsprogs-1.43.5/po/de.po   2017-08-09 18:04:02.361641995 +0200
@@ -7077,14 +7077,13 @@
 msgstr "
pn  fuse2fs
pn  gpart  
ii  parted 3.2-17

-- no debconf information

Bug#871593: mlucas: Please add arm64

[Edmund Grimley Evans]

Source: mlucas
Version: 14.1-2
User: debian-...@lists.debian.org
Usertags: arm64

This package can easily be ported to arm64: in src/platform.h
recognise the architecture with defined(__aarch64__) and configure
it the same as amd64.

Also, the many mentions of "unknown" in platform.h suggest
that the code is intended to work on any system with a working
C compiler, so perhaps it could be made "Architecture: any".

Bug#871269: missing Replaces

[Andreas Beckmann]

On 2017-08-09 18:52, Dirk Eddelbuettel wrote:
> Uploaded a -6 with the versioned Replaces but just got a note it is in NEW
> because of libgsl-prof -- which seems strange.  Any idea?

Since the packaging is not in git (or another vcs), I can't review the
diff ... and NEW is not accessible AFAIK.

I can't find a *gsl*prof* package in the archive, so this indeed seems
to be a new one. And should be totally unrelated to the splitting of the
library package.


Andreas