Bug#844653: [Pkg-mozext-maintainers] Bug#844653: Bug#844653: stylish FTBFS in testing: firefox-dev won't be in stretch

[Mike Hommey]

On Sun, Nov 20, 2016 at 04:40:00PM +1100, Dmitry Smirnov wrote:
> On Thursday, 17 November 2016 9:44:39 PM AEDT Adrian Bunk wrote:
> > firefox-dev is not in stretch, and it is not planned that it
> > ever will be (see #817954).
> > 
> > firefox-esr-dev might be the alternative, but the Mozilla maintainers
> > (Cc'ed on this bug) should be able to give a more definite answer
> > on that.
> 
> What exactly am I expected to do about this bug?? If "firefox-dev" is not 
> meant to be in Stretch than it should have "serious" bug instead of packages 
> that depend on "firefox-dev". 

Wait what? Packages that build depend on a package that is not in
stretch are in stretch? WTF?

> Should I just replace "firefox-dev" with "firefox-esr-dev"?

Probably.

Mike

Bug#826150: spice-vdagent (0.15.0-1.3) is incompatible with xserver-xorg-video-qxl (0.1.4-3)

[intrigeri]

Control: tag -1 + moreinfo

Hi,

> if i start Xspice with --vdagent --vdagent-exec /usr/bin/spice-vdagent 
> --vdagentd-exec /usr/sbin/spice-vdagentd
> options it passes invalid options to spice-vdagentd.

> --- Xspice output ---
> qxl_surface_create: Bad bpp: 1 (1)
> /usr/sbin/spice-vdagentd: invalid option -- 'f'

> Usage: spice-vdagentd [OPTIONS]

> Spice guest agent daemon, version 0.15.0.

> Options:
>   -h print this text
>   -d log debug messages (use twice for extra info)
>   -s   set virtio serial port  
> [/dev/virtio-ports/com.redhat.spice.0]
>   -S   set udcs socket [/var/run/spice-vdagentd/spice-vdagent-sock]
>   -uset uinput device   [/dev/uinput]
>   -x don't daemonize
>   -X Disable systemd-logind integration
> ---

> Referring to the helpful people in #spice IRC Channel at least vdagent 0.16 
> is needed to get
> Xspice working with --vdagent.


Can you still reproduce this with 0.17.0-1?

Bug#844835: orthanc: FTBFS: build-dependency not installable: libssl-dev

[Gert Wollny]

Hi, 

orthnac build depends on libdcmtk-dev, and this pulls in libssl1.0-dev
(since dcmtk (a) does not yet support openssl-1.1 and (b) it is used by
programs that require QT which conflicts with openssl-1.1). 

libssl1.0-dev conflicts with libssl-dev, and hence the build failure. 

The solution is to remove libssl-dev from the build dependencies, since
libdcmtk-dev already takes care of pulling the right version in. 


Best, 
Gert 

Bug#845073: RFS: node-text-encoding/0.6.2-1

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "node-text-encoding"

 * Package name: node-text-encoding
   Version : 0.6.2-1
   Upstream Author : Joshua Bell
 * URL : https://github.com/inexorabletash/text-encoding
 * License : Unlicense
   Section : web

  It builds those binary packages:

libjs-text-encoding - Polyfill for the Encoding Living Standard's 
API (JavaScript lib)
 node-text-encoding - Polyfill for the Encoding Living Standard's API 
(Node.js module)


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


  https://mentors.debian.net/package/node-text-encoding


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

dget -x 
https://mentors.debian.net/debian/pool/main/n/node-text-encoding/node-text-encoding_0.6.2-1.dsc


  It is packaged within the Debian Javascript Maintainers' git repository:
  Vcs-Git: 
https://anonscm.debian.org/git/pkg-javascript/node-text-encoding.git
  Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-javascript/node-text-encoding.git


 The last d/ch entry is:
node-text-encoding (0.6.2-1) unstable; urgency=medium

  * New upstream release.
  * Mark the libjs- package as Multi-Arch: foreig, following tracker's 
hint.

  * Rename the shortname license from (Un)license to Unlicense.

 -- Julien Puydt   Sat, 19 Nov 2016 21:57:28 
+0100



  Cheers,

Snark on #debian-js

Bug#842626: installation-reports: Should warn when installing 32bit on 64bit-capable machine

[Cyril Brulebois]

Samuel Thibault  (2016-10-30):
> My coworker installed Debian on an amd64-capable laptop, but happened to
> take the 32bit ISO image by mistake, and of course we noticed only after
> finishing the installation :)
> 
> She was surprised that there was no warning about installing 32bit on
> 64bit. There could perhaps be for instance a confirm question right
> after selecting the language, and implemented in the hw-detect package,
> and be taught the same for ppc, mips, etc.

FWIW, while the suggestion looks good to me, it's starting to get a bit
late to add translatable material for stretch. We already have troubles
keeping up with translation updates for almost all languages… :/


KiBi.


signature.asc
Description: Digital signature

Bug#844890: Patch for the libvcflib FTBFS

[Adrian Bunk]

Control: tags -1 patch

This is a result of the recent PIE changes in dpkg.

The following patch fixes it:

--- debian/rules.old2016-11-20 07:01:03.0 +
+++ debian/rules2016-11-20 07:01:08.0 +
@@ -2,7 +2,7 @@
 
 # DH_VERBOSE := 1
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
dh $@


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

Bug#844699: ITP: tdiary-style-gfm -- GFM Style for tDiary

[Youhei SASAKI]

Hi,

On Sun, 20 Nov 2016 01:24:01 +0900,
Haruki Tsurumoto  wrote:
> 
> I have seen upstream repository of this, "tdiary-style-gfm.gemspec"
> says license is MIT License, but LICENSE.txt is the GPLv3.
> I think that to fix this mistake is better.

Oh, you are right. thanks for your mention.l

> In addition, tDiary is licensed under the GPLv2(seems not GPLv2+)
>  
> http://metadata.ftp-master.debian.org/changelogs/main/t/tdiary/tdiary_3.1.3-3_copyright
> 
> It can combined with tDiary?

The tDiary >= 5.0 is licensed under GPL-2.0+. This is compatible GPL-3+.

Regards,
Youhei

---
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07

Bug#636871: provide a command-line switch to prefer IPv6 or IPv4

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

metoo

Sometimes a repository is unreachable via IPv6, even though
it got an  record.

Thanx in advance
Harri
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAlgxTIAACgkQCp4qnmbT
gcv86Qf+JSStqPZxl3HqFLkXtV2jjD6fz279sNsnQ+HKFZPDqwdm+RGgV/XDEHLh
/ryDmu7pCrMRZUZszeuWl4xcAK7HlQtChVgYUKRptseKamqlIilmeRfSHovfBgNU
6aU0GcrPb0mnEtjIyvqoxy95Vyu55L/M2ShfNyk5iGPX1hKHSJLLVc9pbVfJd8J8
soXEYB0AP2LZ9iQiTQXttOTPI88xMUKXAmsSi8gqj9vxSP6JcjCrvycMevv4Kw8w
sHnYs8LbnQb8z5TlxScaVDbuE7w+O825XJzV5piRR71xXpHSQ3uSOWkUhAgJf9o9
0cCMERXwhXku4SZJHHKdnkAxpSzQpQ==
=rygN
-END PGP SIGNATURE-

Bug#817236: schroot: no access to pseudo-terminals in new chroots

[Cyril Brulebois]

Ben Hutchings  (2016-11-07):
> On Wed, 09 Mar 2016 10:02:14 +0100 Ansgar Burchardt 
> wrote:
> > Package: schroot
> > Version: 1.6.10-2
> > Severity: important
> > 
> > debootstrap recently replaced the /dev/ptmx device node with a symlink
> > /dev/ptmx -> pts/ptmx[1]. This changed the default permissions from
> > world-writable (0666) for /dev/ptmx to no-access () in chroots[2].
> 
> This is not needed at all from Linux 4.7.  The open operation on
> /dev/ptmx automatically looks up the sibling pts/ directory.  (Also,
> every mount of devpts is a 'new instance'.)
> 
> It seems to me that the change in debootstrap ought to be reverted, as
> it will not be needed in future and it is causing problems for existing
> configurations.

Adding Marco to the loop.


KiBi.


signature.asc
Description: Digital signature

Bug#844918: Fix for the libncursesada FTBFS

[Adrian Bunk]

Control: tags -1 patch

This is a result of the recent PIE changes in dpkg.

The following patch fixes it:

--- debian/rules.old2016-11-20 06:57:23.0 +
+++ debian/rules2016-11-20 06:57:30.0 +
@@ -27,7 +27,7 @@
 # Set some variables #
 ##
 
-DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
+DEB_BUILD_MAINT_OPTIONS=hardening=+all
 include /usr/share/dpkg/default.mk
 include /usr/share/ada/debian_packaging*.mk
 


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

Bug#843348: Network-console ssh session closes immediately

[Cyril Brulebois]

Hi Richard,

Richard Huynh  (2016-11-06):
> Package: installation-reports
> 
> Boot method: network-console
> Image version: 
> https://d-i.debian.org/daily-images/armel/20161105-01:20/kirkwood/network-console/buffalo/ls-qvl/
> Date: 2016/11/05
> 
> Machine: Buffalo Linkstation LS-QVL
> Processor:
> Memory:
> Partitions:
> 
> Output of lspci -knn (or lspci -nn):
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[E]
> 
> Comments/Problems:
> 
> Boots and brings up network and ssh, however immediately closes the
> ssh session upon correct entry of installer:install username and
> password. Image from the 20161021 has the same issue, however one from
> 20160516 does not appear to be affected.

I think this is the same issue as tracked in:
| Bug#844549: network-console broken: no screen to be resumed matching sh

sorry we didn't reply to your bug report sooner.


KiBi.


signature.asc
Description: Digital signature

Bug#844549: network-console broken: no screen to be resumed matching sh

[Cyril Brulebois]

Hi,

Martin Michlmayr  (2016-11-16):
> * Samuel Thibault  [2016-11-16 23:03]:
> > But AIUI the intent was to have screen in ssh connections too.
> 
> I'm not sure what the intent was.  I assume you're right because Roger
> didn't exclude screen from the network-console images.  Personally,
> I'm not sure I see the point of screen in that case because you can
> always open a second SSH connection and open a terminal, but I don't
> have strong feelings either way if there's an advantage of having
> screen in such cases.
> 
> > I'm also thinking that we perhaps want to add -x when resuming a
> > session, so that somebody can connect trough ssh several times ?
> 
> Yes because right now I get this when I open a 2nd connection:
> 
> debug1: Sending env LC_COLLATE = C
> There is a screen on:
> 1356.network(11/16/16 23:24:12) (Attached)
> 
> Apart from this, the patch works for me.

Then I suggest we get that into git and into unstable sooner rather than
later, so that Stretch Alpha 9 gets a fix. I didn't add an errata entry
for that, but might do so later.


KiBi.


signature.asc
Description: Digital signature

Bug#704112: EPSCrop is for EPS

[Sphinx Pinastri]

Every PS file should set the correct page size
using <>setpagedevice.
The %%BoundingBox comment is highly unreliable,
poorly defined, and often wrong. if you have a special
batch of files that depend on %%BoundingBox, they
should be preprocessed to convert this information to
PostScript. Ghostscript works as designed.

Bug#806900: partman-multipath: correct mpath device detection and bindings

[Cyril Brulebois]

Hi,

Hendrik Brueckner  (2015-12-16):
> It's fine to defer them to a follw-up release.  I have continued to
> work on the multipath stuff and I will provide a summary of what I
> think needs to be integrated.  Briefly, there are some additional
> changes on top of those which I'd like to discuss with you and the
> community. 

Sorry it took so long to get back to you, but it seems I'm slowly
crawling through the few thousands unread mails on debian-boot@.

It would be nice if we could tackle multipath issues at some point,
please let me know how I can help.


KiBi.


signature.asc
Description: Digital signature

Bug#742671: seeding base-installer/debootstrap_script with an absolute path emits a warning, and just a codename results in an error

[Cyril Brulebois]

Margarita Manterola  (2016-10-27):
> Tianon's patch is really simple, and not only does it fix the problem,
> but also makes preseeding more flexible. Can it be applied please?

FWIW, experience shows that it *looked* really simple, did *not* fix the
problem, and *did* generate obvious regressions (#844458, #844646, and
friends).

I'm fine with prods being sent, but it would be better to have actual
tests being performed…


KiBi.


signature.asc
Description: Digital signature

Bug#740465: installation-report: consider including Xorg.0.log

[Cyril Brulebois]

Control: reassign -1 installation-report

Samuel Thibault  (2016-10-30):
> Control: reassign -1 installation-reports
> 
> Hello,
> 
> I just noticed some bug reports against the wrong package, reassigning
> them with the content quoted below.

I really meant to file this against the installation-report package,
which is responsible for preparing installation-reports bug reports:
| kibi@wodi:~/debian-installer/packages/installation-report$ dh_listpackages 
| save-logs
| installation-report


KiBi.


signature.asc
Description: Digital signature

Bug#844653: [Pkg-mozext-maintainers] Bug#844653: stylish FTBFS in testing: firefox-dev won't be in stretch

[Dmitry Smirnov]

On Thursday, 17 November 2016 9:44:39 PM AEDT Adrian Bunk wrote:
> firefox-dev is not in stretch, and it is not planned that it
> ever will be (see #817954).
> 
> firefox-esr-dev might be the alternative, but the Mozilla maintainers
> (Cc'ed on this bug) should be able to give a more definite answer
> on that.

What exactly am I expected to do about this bug?? If "firefox-dev" is not 
meant to be in Stretch than it should have "serious" bug instead of packages 
that depend on "firefox-dev". 

Should I just replace "firefox-dev" with "firefox-esr-dev"? How are they 
different?

Thanks.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
-- Winston Churchill


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

Bug#845072: gpsd-clients depends on X11 libraries

[Juliusz Chroboczek]

Package: gpsd-clients
Version: 3.11-3
Severity: wishlist

Gpsd-clients depends on the X11 libraries, which on a headless system
causes it to install over 50MB of useless stuff.  It would be good if this
package could be split into two, one of which does not depend on X11.

Bug#809388: evince: evince aborts after a few seconds without an error message

[Janusz S. Bień]

On Fri, Nov 18 2016 at 21:50 CET, ja...@inspiresomeone.us writes:
> Control: tags -1 - moreinfo unreproducible
>
> On Wed, Nov 16, 2016 at 05:20:52PM +0100, Janusz S. Bień wrote:
>> Another crash,  still a not typical one:
>
> I might have found what's causing it.  Try setting environment variable
> G_SLICE=always-malloc before evince runs and see if that stops the
> crashes.

Unfortunately the crashes still occur.

Best regards

Janusz

--8<---cut here---start->8---

[...]

jsbien@VivoPC-D8:/mnt/MyBookT2/BitBucket/Parkosz/parkosz-traktat/Latin$ ps aux 
| grep evince | grep -v grep 
jsbien   24942  0.0  0.0 187248  4156 ?Ssl  06:01   0:00 
/usr/lib/evince/evinced
jsbien   24946  1.0  0.9 1053680 6 ?   Sl   06:01   0:01 
/usr/bin/evince file:///mnt/MyBookT2/
jsbien@VivoPC-D8:/mnt/MyBookT2/BitBucket/Parkosz/parkosz-traktat/Latin$ gdb 
$(which evince) 24946

[...]

Reading symbols from /usr/bin/evince...Reading symbols from 
/usr/lib/debug/.build-id/e8/82e4684f58f449dc11bda4147b67295eeb60be.debug...done.
done.
Attaching to program: /usr/bin/evince, process 24946
[New LWP 24947]
[New LWP 24948]
[New LWP 24950]
[New LWP 24951]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f408347b56d in poll () at ../sysdeps/unix/syscall-template.S:84
84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) cont
Continuing.
[New Thread 0x7f405d076700 (LWP 25004)]
[New Thread 0x7f405c875700 (LWP 25005)]
[New Thread 0x7f405d877700 (LWP 25006)]
[New Thread 0x7f407950c700 (LWP 25007)]
[Thread 0x7f407950c700 (LWP 25007) exited]
[Thread 0x7f405c875700 (LWP 25005) exited]
[Thread 0x7f405d076700 (LWP 25004) exited]
[Thread 0x7f405d877700 (LWP 25006) exited]
[New Thread 0x7f405d877700 (LWP 25020)]
[New Thread 0x7f405d076700 (LWP 25021)]
[Thread 0x7f405d877700 (LWP 25020) exited]
[New Thread 0x7f405d877700 (LWP 25029)]
[New Thread 0x7f405c875700 (LWP 25030)]
[New Thread 0x7f407950c700 (LWP 25031)]
[Thread 0x7f405d877700 (LWP 25029) exited]
[Thread 0x7f407950c700 (LWP 25031) exited]
[Thread 0x7f405c875700 (LWP 25030) exited]
[New Thread 0x7f405c875700 (LWP 25032)]
[Thread 0x7f405c875700 (LWP 25032) exited]
[Thread 0x7f405d076700 (LWP 25021) exited]
[New Thread 0x7f405d076700 (LWP 25037)]
[New Thread 0x7f405c875700 (LWP 25038)]
[New Thread 0x7f407950c700 (LWP 25039)]
[New Thread 0x7f405d877700 (LWP 25040)]
[Thread 0x7f405d877700 (LWP 25040) exited]
[Thread 0x7f405d076700 (LWP 25037) exited]
[Thread 0x7f405c875700 (LWP 25038) exited]
[New Thread 0x7f405c875700 (LWP 25041)]
[New Thread 0x7f405d076700 (LWP 25042)]
[New Thread 0x7f405d877700 (LWP 25043)]
[Thread 0x7f407950c700 (LWP 25039) exited]
[Thread 0x7f405d076700 (LWP 25042) exited]
[Thread 0x7f405d877700 (LWP 25043) exited]
[Thread 0x7f405c875700 (LWP 25041) exited]
[New Thread 0x7f405c875700 (LWP 25044)]
[Thread 0x7f405c875700 (LWP 25044) exited]
[New Thread 0x7f405c875700 (LWP 25143)]
[New Thread 0x7f405d877700 (LWP 25144)]
[New Thread 0x7f405d076700 (LWP 25145)]
[New Thread 0x7f407950c700 (LWP 25146)]
[Thread 0x7f405c875700 (LWP 25143) exited]
[Thread 0x7f407950c700 (LWP 25146) exited]
[Thread 0x7f405d877700 (LWP 25144) exited]
[New Thread 0x7f405d877700 (LWP 25154)]
[Thread 0x7f405d877700 (LWP 25154) exited]

Thread 26 "pool" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f405d076700 (LWP 25145)]
0x7f4083cc244f in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) quit

[...]

jsbien@VivoPC-D8:/mnt/MyBookT2/BitBucket/Parkosz/parkosz-traktat/Latin$ 
printenv | grep G_SLICE
G_SLICE=always-malloc
jsbien@VivoPC-D8:/mnt/MyBookT2/BitBucket/Parkosz/parkosz-traktat/Latin$ ps aux 
| grep evince | grep -v grep 
jsbien   25251  0.0  0.0 187248  4212 ?Ssl  06:23   0:00 
/usr/lib/evince/evinced
jsbien   25255  5.7  1.2 1164672 100600 ?  Sl   06:23   0:00 
/usr/bin/evince file:///mnt/MyBookT2/
jsbien@VivoPC-D8:/mnt/MyBookT2/BitBucket/Parkosz/parkosz-traktat/Latin$ gdb 
$(which evince) 25255

[...]

Reading symbols from /usr/bin/evince...Reading symbols from 
/usr/lib/debug/.build-id/e8/82e4684f58f449dc11bda4147b67295eeb60be.debug...done.
done.
Attaching to program: /usr/bin/evince, process 25255
[New LWP 25256]
[New LWP 25257]
[New LWP 25259]
[New LWP 25260]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7ffb0621256d in poll () at ../sysdeps/unix/syscall-template.S:84
84  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) cont
Continuing.
[New Thread 0x7ffadaffd700 (LWP 25284)]
[New Thread 0x7ffae0e25700 (LWP 25285)]
[New Thread 0x7ffaf7fff700 (LWP 25286)]
[New Thread 0x7ffad9ffb700 (LWP 25287)]
[Thread 0x7ffad9ffb700 (LWP 25287) exited]
[Thread 0x7ffaf7fff700 (LWP 25286) exited]
[Thread 0x7ffae0e25700 (LWP 25285) exited]
[New Thread 0x7ffae0e25700 (LWP 25293)]
[Thread 0x7ffae0e25700 (LWP 25293) exited]

Bug#681843: Spurious \r in ps2epsi.ps

[Sphinx Pinastri]

First of all, PostScript can have \r, \n, or \r\n line
endings or any combination thereof. So the blame should be
directed to gv, rather than ps2epsi.

Yet, inconsistent line endings look strange. The original gs
has \n everywhere; it never had this bug. Somebody has
introduced it in the distribution. Please roll this change back.
--- /usr/share/ghostscript/9.10/lib/ps2epsi.ps	2015-07-29 16:51:57.0 -0400
+++ ghostscript-9.18/lib/ps2epsi.ps	2015-10-05 04:21:11.0 -0400
@@ -190,8 +190,8 @@
  epsifile (\n) writestring
  epsifile flushfile
 
-epsifile BBoxString writestring epsifile (\r) writestring
-epsifile HiresBBoxString writestring epsifile (\r) writestring
+epsifile BBoxString writestring epsifile (\n) writestring
+epsifile HiresBBoxString writestring epsifile (\n) writestring
 
 % Define character and bit widths for the output line buffer:
  /cwidth rm lm sub 1 add def

Bug#559953: Problems with item delivery, n.4139527516

[FedEx Standard Overnight]

Hello,
Courier was unable to deliver the parcel to you. You can review complete 
details of your order in the find attached.
Elle Pine - Area Manager FedEx , CA
Kind regards


FedEx.doc
Description: MS-Word document

Bug#792163: Reviewing kipi-plugins dependencies

[Steve M. Robbins]

On Wednesday, November 16, 2016 9:11:56 AM CST you wrote:
> On 16/11/16 06:49, Steve M. Robbins wrote:
> > On Tuesday, November 15, 2016 2:05:27 PM CST Simon Frei wrote:
> >> I second this request. Please make konqueror a suggested package instead
> >> of a recommended. Digikam is aiming to be a cross-platform/-DE
> >> applications, especially since version 5 where many parts have been
> >> ported to QT from KDE framework.
> > 
> > I agree in principle.  Before making the change, I want to check the code
> > to see whether or not anything actually calls konqueror.
> > 
> > -Steve
> 
> I just had a quick grep look and the only place "konqueror" shows up as
> a string is in flashexport and remotestorage. In both cases there is no
> explicit call to konqueror, only calls to QDesktopServices::openUrl or
> KRun::runUrl (or konqueror is just used as an example in a UI string).
> So removing konqueror shouldn't be a problem.

Great, thanks for checking!
-Steve


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

Bug#845055: markdown: please make the output reproducible

[Matt Kraai]

Hi,

On Sat, Nov 19, 2016 at 10:48:56PM +0100, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that markdown generates non-reproducible output.
> 
> Patch attached.

Thank you for the report and patch!  I've uploaded a new version of
the package.

-- 
Matt   https://ftbfs.org/~kraai/

Bug#833217: bug #833217 - Uses obsolete compressor for .deb data.tar member

[Ramakrishnan Muthukrishnan]

fixed 833217 0.7.1-1
thanks

Bug#842040: Please add https support

[Cyril Brulebois]

Hi all,

Philipp Kern  (2016-10-26):
> Which I guess boils down to adding wget-udeb to the installer's
> pkg-lists/base because I think all flavors and all architectures
> should have the same feature set.

That would seem fair to me.

> I'm not sure how you got this number (from a d-i rebuild?), but I end
> up with 22580517B (~same) to 23106785B (2.3% increase) when rebuilding
> amd64 netboot from d-i git. Of course it's way less percentage-wise
> for the default amd64 netboot-gtk (which has a 44696935B initrd right
> now).

I think Marga mentioned on IRC she was unpacking/repacking the initrd
manually.

> So at least size-wise this shouldn't be very controversial. Adding
> wget-udeb to pkg-lists/base ends up with this:
> 
> $ lsinitrd dest/netboot/debian-installer/amd64/initrd.gz | grep wget
> -rwxr-xr-x   1 root root   409016 Sep 26 15:11 usr/bin/wget
> 
> So that seems to have the desired result. I did not try out the
> resulting installer, though.

Well, I think this is a crucial issue: what use case(s) are you trying
to fix? “We want https” isn't clear to me.

Besides wget supporting https, is there any work needed on the retriever
side? What about trust chains, do you have any bundled list of trusted
CAs? Do you want to be able to rebuild d-i with a specific trusted CA,
and trust none by default?


KiBi.


signature.asc
Description: Digital signature

Bug#842040: Please add https support

[Cyril Brulebois]

Jose R R  (2016-11-18):
> The official Debian maintainer(s) busybox source lacks a directory
> that is upstream in the busybox official source.

I think the main issue here is that busybox in Debian lacks a
maintainer.

The other is that matrixssl isn't packaged in Debian, as already
pointed out.


KiBi.


signature.asc
Description: Digital signature

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

[Cyril Brulebois]

Hi,

Dimitri John Ledkov  (2016-11-18):
> I am not at all sure if this functionality is at all welcomed, needed,
> or will generate any interest. I do not know if it's wanted to be
> available by default in Debian's d-i. At the moment I created a git
> repository in the d-i team, and plan to upload this to experimental
> for people to try this out.

Without having any opinions on your goals and reasons for them, it looks
to me we're already rather late in the release cycle, probably a bit too
much to consider going through that kind of changes now.


KiBi.


signature.asc
Description: Digital signature

Bug#844458: bootstrap-base: if debootstrap_script is unset, DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install

[Cyril Brulebois]

Hi,

Philip Hands  (2016-11-18):
> That's a preseeded test.  I've also installed jessie with that, as a
> manual install, and at least started a default stretch install (it's
> gone past the pointof error...) so I think that indicates that it works
> 
> I didn't bother to test using the full path in 
> base-installer/debootstrap_script.
> 
> Given that it works, I'll apply that patch to the master branch.

so I've reviewed it earlier today, looked good, so it was uploaded.

Trying a netboot image, with mirror/udeb/suite=unstable, the 1.167
version got uploaded, and debootstrap worked just fine.

Thanks!


KiBi.


signature.asc
Description: Digital signature

Bug#829645: src:gtest: Cannot build against libgtest-dev with std=c++11

[Steve M. Robbins]

Hi,

On Mon, Jul 04, 2016 at 05:51:20PM -0700, Afif Elghraoui wrote:
> Package: src:gtest
> Version: 1.7.0-4
> Severity: important

The googletest package has recently been updated to 1.8.0
and built with gcc 6.  So I expect this issue is gone, but
I'd like you to test it and let me know because I can't
easily reproduce it even with version 1.7.0-4.

> I'm trying to enable tests for the pbbam package, but there is a
> compilation error that is triggered by simply including gtest.h:

I attempted to reproduce using the following file, but it succeeds
without error.

#include 

int main()
{
return 0;
}


> 
> Line 43 of my file /<>/tests/src/test_AlignmentPrinter.cpp has:
> 
> #include 

I am unable to compile tests/src/test_AlignmentPrinter.cpp; I get this
error:

g++ --std=c++11 -c tests/src/test_AlignmentPrinter.cpp 
tests/src/test_AlignmentPrinter.cpp:42:22: fatal error: TestData.h: No such 
file or directory
 #include "TestData.h"
  ^
compilation terminated.


Can you let me know if the new package fixes this bug?

Thanks!
-Steve


signature.asc
Description: PGP signature

Bug#844785: systemd prevents polkit from working properly

[Adam Bolte]

On 20/11/16 15:13, Raphaël Halimi wrote:
> Control: retitle -1 systemd-shim not fully compatible with systemd
> 232 Control: affects -1 policykit-1 policykit-1-gnome mate-polkit
>
> Le 20/11/2016 à 04:21, Adam Bolte a écrit : Right. I retitled the bug
> to more precisely describe the problem, and added affected packages
> (at least the ones I tried...

Thanks! That's a great idea.


> Yeah, that's basically what I did, except with systemd 231-10.

I saw 231-10, but wasn't sure it ever made it to testing (possibly
suggesting a problem with it). I could be mistaken, but I never had it
installed on my machine at least, and I do upgrade reasonably often.


> I then pinned systemd with a preferences file, and now apt is
> holding libpam-systemd and libsystemd0 too, but accepted to upgrade
> udev and libudev1 (I initially thought that there would be a
> versioned dependency between the two sets, but that's not the case).
> So in fact, only those three packages (four in case of multi-arch)
> have to be downgraded to restore the system to a functional state.

Thanks for reporting. I'll just pin those packages for now too then.

Cheers,
Adam




signature.asc
Description: OpenPGP digital signature

Bug#845071: ITP: node-core-js -- Javascript Standard library

[Sruthi Chandran]

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

* Package name: node-core-js
  Version : 2.4.1
  Upstream Author : FIX_ME upstream author
* URL : https://github.com/zloirock/core-js#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Javascript Standard library

Bug#845070: ITP: node-loader-utils -- utils for webpack loaders

[Pirate Praveen]

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

* Package name: node-loader-utils
  Version : 0.2.16
  Upstream Author : Tobias Koppers @sokra
* URL : https://github.com/webpack/loader-utils#readme
* License : Expat
  Programming Lang: JavaScript
  Description : utils for webpack loaders



signature.asc
Description: OpenPGP digital signature

Bug#844495: [pkg-boost-devel] Bug#844495: Bug#844490: FTBFS with boost1.62

[Steve M. Robbins]

On Wednesday, November 16, 2016 12:16:22 PM CST Thibaut Paumard wrote:
> Control: tags 844490 +pending
> Control: severity 844495 normal
> 
> For the record, the bug appears when doing:
> 
> acos(cos(alpha100)*cos(delta100));
> 
> where the type of alpha100 and delta100 is
> boost::multiprecision::cpp_dec_float_100.
> 
> I've realized that, when acos() does not return, delta100 above is
> always zero. I can simplify the case by simply doing
> acos(cos(alpha100))
> 
> in which case acos() also does not return. Does not look like a memory
> leak after all.
> 
> However, doing just that in an isolated main function does not exhibit
> the bug (I've also tried activating all the hardening features)

So when you say "doing just that" in isolated main ... do you mean
doing
acos(cos(alpha100)*cos(delta100)) 
or
acos(cos(alpha100))?

Did you succeed to find any small test case at all?  It would be good to have 
one and report it upstream.

Thanks,
-Steve


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

Bug#844785: systemd prevents polkit from working properly

[Raphaël Halimi]

Control: retitle -1 systemd-shim not fully compatible with systemd 232
Control: affects -1 policykit-1 policykit-1-gnome mate-polkit

Le 20/11/2016 à 04:21, Adam Bolte a écrit :
> It took about an hour to find this bug report, since I was looking for
> changes related to consolekit, polkit, pam, etc. I've been using using
> sysvinit-core to avoid systemd issues (systemd doesn't even boot for me
> for some reason I don't care to investigate), so it didn't immediately
> occur to me to look at possible systemd libraries changes. I wouldn't be
> surprised if a lot of people hitting this don't know to look here.

Right. I retitled the bug to more precisely describe the problem, and
added affected packages (at least the ones I tried, I guess lxsession
(which provides lxpolkit) is affected too, but I didn't actually try it,
so I'll let that to someone who actually did, and can confirm that LXDE
loses functionality as well).

I'm worried though, because systemd-shim is orphaned now.

> As a work-around, look through the log to get the systemd-related
> packages which were upgraded:
> 
> $ grep 232-3 /var/log/dpkg.log | grep ' status installed ' | \
>   cut -d ' ' -f 5 | sort | uniq
> libpam-systemd:amd64
> libsystemd0:amd64
> libsystemd0:i386
> libudev1:amd64
> libudev1:i386
> libudev-dev:amd64
> systemd:amd64
> udev:amd64
> 
> Then head over to http://snapshot.debian.org/package/systemd/231-9/ and
> download the debs for each of the above. Check the hashes, and install:
> 
> # dpkg -i *.deb
> 
> Reboot, and now you can shutdown via lightdm, mount drives, etc as normal.

Yeah, that's basically what I did, except with systemd 231-10. I then
pinned systemd with a preferences file, and now apt is holding
libpam-systemd and libsystemd0 too, but accepted to upgrade udev and
libudev1 (I initially thought that there would be a versioned dependency
between the two sets, but that's not the case). So in fact, only those
three packages (four in case of multi-arch) have to be downgraded to
restore the system to a functional state.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#844721: libgtest-dev isn't replacing dir with symlink on upgrade

[Steve M. Robbins]

On Fri, Nov 18, 2016 at 01:29:07PM +0100, David Kalnischkies wrote:

> libgtest-dev contains in 1.8.0-1 a symlink to the new on-disk location.
> That works for new installs, but doesn't on upgrades ??? a user ends up
> with an empty /usr/src/gtest in that case.  You need to work with
> maintainerscripts here, see "man dpkg-maintscript-helper" and especially
> the section about dir_to_symlink for details on how and why.

I agree that upgrades should work and regret not testing that case.
Thank you very much for a very precise pointer to the fix!  Will
upload very soon.

> You should also update your README.Debian and the descriptions with the
> new paths and the transitional package as [...]

Thanks.  Updated README.Debian.  Not sure what you mean about the
descriptions -- there is nothing in the control file about the
paths. (?)


> btw: Upstream seems to have retired their remark on compiling googletest
> on your own as I can't find it any longer on their website and e.g. in
> the RPM/BSD worlds you get a binary only.

Hmm.  The code still has a lot of #if/#ifdef code in it including at
least one "#ifdef NDEBUG".  I haven't done an in-depth look, but I'd
think the advice about not distributing a compiled version would still
hold.

Best,
-Steve


signature.asc
Description: PGP signature

Bug#844785: systemd prevents polkit from working properly

[Adam Bolte]

It took about an hour to find this bug report, since I was looking for
changes related to consolekit, polkit, pam, etc. I've been using using
sysvinit-core to avoid systemd issues (systemd doesn't even boot for me
for some reason I don't care to investigate), so it didn't immediately
occur to me to look at possible systemd libraries changes. I wouldn't be
surprised if a lot of people hitting this don't know to look here.

On Sat, 19 Nov 2016 09:35:32 -0300 Felipe Sateler 
wrote:
> Because you use sysvinit, this means the systemd-shim compatibility
> layer is not working for 232. I'm reassigning so that it can be fixed.

Confirming this all seems accurate. I too am using systemd-shim (which
was not updated in a while.

As a work-around, look through the log to get the systemd-related
packages which were upgraded:

$ grep 232-3 /var/log/dpkg.log | grep ' status installed ' | \
  cut -d ' ' -f 5 | sort | uniq
libpam-systemd:amd64
libsystemd0:amd64
libsystemd0:i386
libudev1:amd64
libudev1:i386
libudev-dev:amd64
systemd:amd64
udev:amd64

Then head over to http://snapshot.debian.org/package/systemd/231-9/ and
download the debs for each of the above. Check the hashes, and install:

# dpkg -i *.deb

Reboot, and now you can shutdown via lightdm, mount drives, etc as normal.

Cheers,
Adam



signature.asc
Description: OpenPGP digital signature

Bug#779804: Updated maxima-ecl debdiff for maxima 5.38.1-2

[Ximin Luo]

Camm Maguire:
> [..]
> 
> It is a pity that as sage offers a viable alternative, it has
> nevertheless been passed over.  I hear concerns about human resources,
> but then when I offer to help make it work and request a status report
> all I get is predetermined conclusions to not make it work.
> 

I am sorry we did not give you a proper status update - but to be honest that 
is because we did nothing significant to actually report to you. We had so many 
other things to do, there was no time to do anything on Maxima, of the depth 
that this task (using GCL) would have required. Please believe me when I say 
this - you can check our mailing list, the wiki page history, and our git logs, 
for our activity over the past several weeks and even months.

I did in fact spend several (5-8) hours researching the topic and concluded it 
was not feasible for me to even *start trying* myself - but see below for 
further comments.

> [..]  But relying on internal structure which the
> developers do not commit to maintain as a stable api is just asking for
> this duplication of effort and *waste* of human resources.  I know this
> from experience [..]

That is Sage upstream's decision to make, whether to waste their own time or 
not. It doesn't affect us Debian maintainers - the ECL patch is minimal. As I 
understand, they have judged it to be more beneficial to risk this, because 
linking directly with the internal library allows them to implement more 
features.

I totally understand that this is generally something to be avoided. But in 
specific circumstances, one can make it work. From looking at the bug reports, 
Sage upstream seem to be quite "on the ball" on this one, and have helped catch 
several regressions in Maxima.

> I assure you that I can get the print interface to work.  In fact I
> will pledge to be solely responsible for ensuring that tests of this
> interface pass at the standard designed upstream should we agree to go
> this way.  It would make sense in such a case for me to join your group
> and co-maintain sage with you.
> 

We'd be more than happy if you wanted to do this and get Sage working with 
maxima-with-GCL, and keep this working! But the key question is, what do you 
plan to do regarding the FASL library and the ECL sage/interfaces/maxima_lib 
interface?

In my limited understanding, one would have to modify quite a lot of internal 
Sage code, to make it instead use the Maxima print interface. This is 
definitely something to be discussed further with Sage upstream, and will take 
quite some time. Again, if you want to do this then we would be perfectly happy 
to accept any results that come out of it! But we didn't think it was within 
our capacity to do this, given all the other things that needed to be done.

> [..]

Thanks for this continued discussion!

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#845069: /etc/init.d/camo should redirect stderr as well as stdout

[Anders Kaseorg]

Package: camo
Version: 2.3.0+dfsg-2
Tags: patch
X-Debbugs-CC: lfara...@debian.org

‘/etc/init.d/camo start’ was leaving camo’s stderr attached to the outside 
terminal.

diff --git a/debian/changelog b/debian/changelog
index 9a74aa3..59019b4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+camo (2.3.0+dfsg-2) unstable; urgency=medium
+
+  * /etc/init.d/camo: Redirect stderr as well as stdout.
+
+ -- Anders Kaseorg   Sat, 19 Nov 2016 22:20:45 -0500
+
 camo (2.3.0+dfsg-1) unstable; urgency=medium
 
   [ Luke Faraone ]
diff --git a/debian/init b/debian/init
index bd16c7d..ccb7a55 100644
--- a/debian/init
+++ b/debian/init
@@ -51,10 +51,10 @@ do_start()
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
-   start-stop-daemon --start --quiet --pidfile $PIDFILE -bm --exec $DAEMON 
--no-close -c nobody --test > /dev/null \
+   start-stop-daemon --start --quiet --pidfile $PIDFILE -bm --exec $DAEMON 
--no-close -c nobody --test > /dev/null 2>&1 \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE -bm --no-close -c 
nobody --exec $DAEMON -- \
-   $DAEMON_ARGS >> /var/log/camo/camo.log  \
+   $DAEMON_ARGS >> /var/log/camo/camo.log 2>&1 \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend

Bug#806984: debian-installer: FTBFS: File not found:libtextwrap.so.1

[Cyril Brulebois]

Control: severity -1 important

Hi,

Val Lorentz  (2015-12-03):
> Source: debian-installer
> Version: 20151023
> Severity: serious
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi!
> 
> While working on the “reproducible builds” effort [1], we have noticed
> that debian-installer could not be built in some configurations.
> It could be an effect of any of the commands in [2], but it is likely to
> be the locale.
> 
> The attached file contains the full build logs.
> 
>  [1]: https://wiki.debian.org/ReproducibleBuilds
>  [2]: 
> https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=reproducible/misc.git;a=blob;f=prebuilder/pbuilderhooks/A02_user;h=a3c8ceb9a4e5b0aa069e146bc50d3757d89a2e1f;hb=b012c16d7349a30b3c906851c171670abbced407
> 
> Regards,
> Valentin

Looking at your A02_user hook, I don't see anything locale-related (now or
in previous commits). I've tried setting LANG=fr_CH.UTF-8 and I don't see
debian-installer's master fail to build in a sid chroot.

Can you please tell us whether this issue is still seen in your setup, and
with which exact settings? I can't replicate it with my devel chroots,
it's not seen on buildds, so I'm lowering the severity for the time being.
It can be upgraded again if a relevant reproducer is found.

Thanks for your time.


KiBi.


signature.asc
Description: Digital signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Cyril Brulebois]

Christian PERRIER  (2016-11-19):
> I now need to figure out where to make other changes.
> 
> One is in the installer build files (in the debian-installer package
> itself) and is committed to git.

Maybe you forgot to push that part? I've mentioned it earlier when I
noticed the rootskel-gtk upload (and only saw this thread afterwards):
  https://lists.debian.org/debian-boot/2016/11/msg00178.html

> Another is in one of the D-I packages : changing the file that mentions
> what fonts are used depending on the locale. This is not yet committed
> as I now have to remember what package we're talking about..:-)

That was indeed rootskel-gtk's gtk-set-font as you found out; sorry for
being late to the party.


KiBi.


signature.asc
Description: Digital signature

Bug#844596: dpkg-gensymbols doesn't update arch-bits when called with -a

[Guillem Jover]

Control: tag -1 moreinfo unreproducible

Hi!

On Thu, 2016-11-17 at 10:57:10 +0100, Matthias Klose wrote:
> Package: dpkg-dev
> Version: 1.18.15
> Severity: important

> When dpkg-gensymbols is called with -a, it doesn't update the arch-bits
> information, and keeps them set for the default architecture, even if the
> default doesn't match the parameter.  I didn't check for the endianness
> information, but I assume it's the same.

I'm not sure I understand the report. The arch-bits and
arch-endianness are matches for specific symbols, they get matched
against the information from the default or specified architecture,
I'm not sure were or how you expect those values to be updated.
Including a recipe to get there would be helpful or giving more
detail.

Thanks,
Guillem

Bug#844701: dpkg: buggy dpkg 1.8.11 and above ? Package: dpkg

[Guillem Jover]

Control: retitle -1 dpkg-maintscript-helper: Version comparison fails for 
supposedly valid versions
Control: severity -1 serious

Hi!

On Fri, 2016-11-18 at 14:02:39 +0530, shirish शिरीष wrote:
> Package: dpkg
> Version: 1.18.14
> Severity: normal

> It seems the bug is in dpkg 1.18.11 and above. I was suffering from
> some sort of broken packages. I shared my issue at
> http://unix.stackexchange.com/questions/323817/debian-strech-update-broken-seems-buggy-dpkg
> . It took quite some time but it seems that dpkg at least 1.18.14 is
> somewhat broken/buggy in its implementation. In dpkg 1.18.10 I am able
> to fix the broken packages. These happened a few more times. I did run
> a few checks 
> http://unix.stackexchange.com/questions/324151/how-to-find-out-half-configured-broken-packages-in-debian
> but found nothing untoward.

Please include your reports inline, instead of referencing outside
resources, because this means those details might disappear (in the
future) in case those sites are shutdown, or it requires maintainers
to be online to check them.

Ok, so this is about the dpkg-maintscript-helper failing on the
version validation check for supposedly valid versions. This was
recently reported on IRC too, but we were unable to reproduce it. If
you can still reproduce it, I'd appreciate if you could apply the
attached patch to your installed dpkg-maintscript-helper script
(from a dpkg version > 1.18.11) and rerun the failing package.

Oh, I think I know what's wrong now, the attached patch should in
principle fix that.

Thanks,
Guillem
diff --git i/scripts/dpkg-maintscript-helper.sh w/scripts/dpkg-maintscript-helper.sh
index f20d82647..8db4a4088 100755
--- i/scripts/dpkg-maintscript-helper.sh
+++ w/scripts/dpkg-maintscript-helper.sh
@@ -49,8 +49,9 @@ rm_conffile() {
 	[ "${CONFFILE}" != "${CONFFILE#/}" ] || \
 		error "conffile '$CONFFILE' is not an absolute path"
 	# Use --compare-versions to validate the version number.
-	[ -z "$(dpkg --compare-versions -- "$LASTVERSION" eq '0' 2>&1)" ] || \
-		error "version '$LASTVERSION' is not valid"
+	VERSIONCHECK="$(dpkg --compare-versions -- "$LASTVERSION" eq '0' 2>&1 || true)"
+	[ -z "$VERSIONCHECK" ] || \
+		error "version '$LASTVERSION' is not valid: $VERSIONCHECK"
 
 	debug "Executing $0 rm_conffile in $DPKG_MAINTSCRIPT_NAME" \
 	  "of $DPKG_MAINTSCRIPT_PACKAGE"
@@ -163,8 +164,9 @@ mv_conffile() {
 	[ "${NEWCONFFILE}" != "${NEWCONFFILE#/}" ] || \
 		error "new-conffile '$NEWCONFFILE' is not an absolute path"
 	# Use --compare-versions to validate the version number.
-	[ -z "$(dpkg --compare-versions -- "$LASTVERSION" eq '0' 2>&1)" ] || \
-		error "version '$LASTVERSION' is not valid"
+	VERSIONCHECK="$(dpkg --compare-versions -- "$LASTVERSION" eq '0' 2>&1 || true)"
+	[ -z "$VERSIONCHECK" ] || \
+		error "version '$LASTVERSION' is not valid: $VERSIONCHECK"
 
 	debug "Executing $0 mv_conffile in $DPKG_MAINTSCRIPT_NAME" \
 	  "of $DPKG_MAINTSCRIPT_PACKAGE"

Bug#742110: Problem with parcel shipping, ID:234573637388

[FedEx International Next Flight]

Hello,
We could not deliver your parcel. Shipment Label is attached to this email.
Reeba Wittenborn - Area Manager FedEx , CA
Thanks and best regards


FedEx.doc
Description: MS-Word document

Bug#845068: bluez: Impossible to set bluez while dist-upgrade

[Jean-Philippe MENGUAL]

Package: bluez
Version: 5.43-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

On Stretch, I dist-upgrade the system.

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

apt dist-upgrade

   * What was the outcome of this action?

Setting bluez (5.43-1) ...
Job for bluetooth.service failed because the control process exited with error 
code.
See "systemctl status bluetooth.service" and "journalctl -xe" for details.
invoke-rc.d: initscript bluetooth, action "restart" failed.
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2016-11-20 03:03:47 CET; 12ms 
ago
 Docs: man:bluetoothd(8)
  Process: 26402 ExecStart=/usr/lib/bluetooth/bluetoothd (code=exited, 
status=1/FAILURE)
 Main PID: 26402 (code=exited, status=1/FAILURE)
   Status: "Starting up"

nov. 20 03:03:47 hypra systemd[1]: Starting Bluetooth service...
nov. 20 03:03:47 hypra bluetoothd[26402]: Bluetooth daemon 5.43
nov. 20 03:03:47 hypra bluetoothd[26402]: D-Bus setup failed: Failed to connect 
to socket /var/run/dbus/system_bus_socket: Permission denied
nov. 20 03:03:47 hypra systemd[1]: bluetooth.service: Main process exited, 
code=exited, status=1/FAILURE
nov. 20 03:03:47 hypra systemd[1]: Failed to start Bluetooth service.
nov. 20 03:03:47 hypra systemd[1]: bluetooth.service: Unit entered failed state.
nov. 20 03:03:47 hypra systemd[1]: bluetooth.service: Failed with result 
'exit-code'.
dpkg: erreur de traitement du paquet bluez (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de 
sortie d'état 1
dpkg: des problèmes de dépendances empêchent la configuration de bluetooth :
 bluetooth dépend de bluez ; cependant :
 Le paquet bluez n'est pas encore configuré.

dpkg: erreur de traitement du paquet bluetooth (--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 bluez
 bluetooth
E: Sub-process /usr/bin/dpkg returned an error code (1)
r

   * What outcome did you expect instead?

Should set. But a problem here. Due to dbus? systemd? I don't know.

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

Here permissions:
srw-rw-rw- 1 root root 0 nov.  19 04:01 /var/run/dbus/system_bus_socket

I don't use selinux or apparmor, but
libselinux1:amd64 and libapparmor1:amd64 are installed.

Available for further investigations.

Regards,


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

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

Versions of packages bluez depends on:
ii  dbus 1.10.12-1
ii  init-system-helpers  1.46
ii  kmod 23-1
ii  libc62.24-5
ii  libdbus-1-3  1.10.12-1
ii  libglib2.0-0 2.50.2-1
ii  libreadline7 7.0-1
ii  libudev1 232-3
ii  lsb-base 9.20161101
ii  udev 232-3

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- debconf-show failed

Bug#837478: Static libraries - PIC or PIE?

[Phillip Hellewell]

Consider this use case for an end user with 64-bit Debian 9:
- Compiles an executable with gcc, linking a few libraries like ICU,
openssl, bz2, etc.  Works fine.
- Now tries to link a few of the libraries statically (e.g.,
libicuuc.a).  ld blows up with a bunch of relocation R_X86_64_32S, blah
blah blah, recompile with -fPIC errors.

This was me a few hours ago, when I found about all this the hard way.

Problem is, an end user has absolutely no idea what they're doing wrong or
how to fix it.  They have no idea that GCC 6 in Debian 9 now has PIE on by
default.  They have no idea what PIE is.  They have no idea if they must
recompile their own code with -fPIC or rebuild the 3rdparty libraries with
it.  They do not believe they should have to rebuild 3rdparty libraries
(why isn't the distro's version of them working)?  They also have no idea
that they can work around the problem using -no-pie if they don't care
about PIE.

All they know is that for some reason they can't link most libraries
statically without getting a bunch of weird errors.  It could take hours of
research to figure out a workaround like -no-pie.

Given that GCC 6 on Debian 9 now does PIE executables by default, I think
it becomes very necessary to consider that Debian out to build all static
libraries with -fPIE (or -fPIC).  Otherwise you're going to get thousands
and thousands of users having no clue why they can't link anything
statically.  Plus if you did that you wouldn't have to build everything
twice.  Win-Win !!!  So why not?

Thanks,
Phillip

Bug#845062: ifrench-gut: FTBFS when built with dpkg-buildpackage -A (dpkg-genbuildinfo: error: cannot fstat file ../ifrench-gut_1.0-31_amd64.deb)

[Guillem Jover]

Control: reassign -1 src:ifrench-gut
Control: tag -1 patch

Hi!

On Sat, 2016-11-19 at 23:33:59 +, Santiago Vila wrote:
> Package: src:ifrench-gut,dpkg-dev
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in sid with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> debian/patches/automakehash.dpatch -patch
> patching file makehash
> Hunk #1 succeeded at 146 (offset 1 line).
> Hunk #2 succeeded at 193 (offset 1 line).
> Hunk #3 succeeded at 273 (offset 1 line).
> debian/patches/autodicooption.dpatch -patch
> patching file makehash
> Hunk #2 succeeded at 40 (offset 1 line).
> Hunk #3 succeeded at 163 (offset 1 line).
> Hunk #4 succeeded at 199 (offset 1 line).
> Hunk #5 succeeded at 422 (offset 1 line).
> debian/patches/replacement_aff.dpatch -patch
> 
> [... snipped ...]
> 
> chercher ses dictionnaires.
> Probablement : /usr/lib/ispell
> 
> (Faites de m�me pour ./francais-TeX8b.aff et ./francais-TeX8b.hash.)
> 
> is2my-spell.pl francais.aff > fr-pre.aff
> LC_ALL=C sed -e 's/^SET.*/SET ISO8859-15/;s/^TRY.*/TRY 
> aeio��sinrtlcdugmphbyfvkw���/' fr-pre.aff > fr.aff
> wc -l < francais.dico > francais.dico.cnt
> cat francais.dico.cnt francais.dico > fr.dic
> touch build-stamp
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_prep
> dh_installdirs
> dh_installdirs: Compatibility levels before 9 are deprecated (level 7 in use)
> # Add here commands to install the package into debian/ifrench-gut.
> install -m 0644 fr.aff 
> /<>/debian/myspell-fr-gut/usr/share/hunspell
> install -m 0644 fr.dic 
> /<>/debian/myspell-fr-gut/usr/share/hunspell
> # links for myspell dicts
> ln -s /usr/share/hunspell/fr.aff 
> /<>/debian/myspell-fr-gut/usr/share/myspell/dicts/fr.aff
> ln -s /usr/share/hunspell/fr.dic 
> /<>/debian/myspell-fr-gut/usr/share/myspell/dicts/fr.dic
> for CC in FR BE LU CH; do for SUF in aff dic; do\
>   ln -s fr.${SUF} 
> /<>/debian/myspell-fr-gut/usr/share/hunspell/fr_${CC}.${SUF}; \
>   ln -s /usr/share/hunspell/fr.${SUF} 
> /<>/debian/myspell-fr-gut/usr/share/myspell/dicts/fr_${CC}.${SUF};
>  \
> done; done
> dh_testdir
> dh_testroot
> dh_installdocs
> dh_installdocs: Compatibility levels before 9 are deprecated (level 7 in use)
> dh_installchangelogs
> dh_installchangelogs: Compatibility levels before 9 are deprecated (level 7 
> in use)
> dh_link
> installdeb-myspell -p myspell-fr-gut
> dh_compress
> dh_fixperms
> dh_installdeb -i
> dh_installdeb: Compatibility levels before 9 are deprecated (level 7 in use)
> dh_gencontrol
> dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
> not NFS-safe
> dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
> not NFS-safe
> dh_md5sums
> dh_builddeb -i
> dpkg-deb: building package 'myspell-fr-gut' in 
> '../myspell-fr-gut_1.0-31_all.deb'.
>  dpkg-genbuildinfo --build=all
> dpkg-genbuildinfo: error: cannot fstat file ../ifrench-gut_1.0-31_amd64.deb: 
> No such file or directory
> dpkg-buildpackage: error: dpkg-genbuildinfo --build=all gave error exit 
> status 2
> 
> 
> The package does not use dpkg-genbuildinfo explicitly, so this seems
> like a bug in dpkg-dev.
> 
> On the other hand, if this were a bug in dpkg-dev, I would expect to
> find a lot more packages with the same problem, but I only found this
> one.
> 
> So this is really strange and I don't really know where is the bug.
> Please do agree on which package is to blame.

This package has broken debhelper usage, it does not specify neither
-a nor -i flags for debhelper commands, so the DEBIAN/control file
gets generated for both all and any packages, and dpkg-gencontrol
registers the to be generated .deb into debian/files, but then those
never end up being generated.

See the attached patch.

Thanks,
Guillem

--- rules	2016-11-20 03:07:24.0 +0100
+++ /tmp/bi/ifrench-gut-1.0.new/debian/rules	2016-11-20 02:18:26.008988076 +0100
@@ -90,15 +90,15 @@
 binary-indep: build install-indep
 	dh_testdir
 	dh_testroot
-	dh_installdocs
-	dh_installchangelogs
-	dh_link
+	dh_installdocs -i
+	dh_installchangelogs -i
+	dh_link -i
 	installdeb-myspell -p myspell-fr-gut
-	dh_compress
-	dh_fixperms
+	dh_compress -i
+	dh_fixperms -i
 	dh_installdeb -i
-	dh_gencontrol
-	dh_md5sums
+	dh_gencontrol -i
+	dh_md5sums -i
 	dh_builddeb -i
 
 # Build architecture-dependent files here.
@@ -106,30 +106,29 @@
 binary-arch: build install-arch
 	dh_testdir
 	dh_testroot
-#	dh_installdebconf	
+#	dh_installdebconf -a
 	installdeb-ispell -p ifrench-gut # new policy (see dict-common) - calls dh_installdebconf
-	dh_installdocs
-#	dh_installexamples
-#	dh_installmenu
-#	dh_installlogrotate
-#	dh_installemacsen
-#	dh_installpam
-#	dh_installmime
-#	dh_installinit
-#	dh_inst

Bug#844924: pygobject: FTBFS: Tests failures

[Emilio Pozuelo Monfort]

On 20/11/16 02:58, Michael Biebl wrote:
> Am 20.11.2016 um 02:45 schrieb Emilio Pozuelo Monfort:
>> On 20/11/16 01:44, Michael Biebl wrote:
>>> Am 19.11.2016 um 08:03 schrieb Lucas Nussbaum:
 Source: pygobject
 Version: 3.22.0-1
 Severity: serious
 Tags: stretch sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20161118 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):
> if 'generic-c-marshaller' in GObject.features:
> ^
> pygtkcompat/pygtkcompat.py:102:1: E305 expected 2 blank lines after class 
> or function definition, found 1
> _unset = object()
> ^
>>>
>>> Looks like pep8 got stricter (again).
>>> There were some new upstream releases just recently.
>>> I got some build failures in other packages as well.
>>>
>>> Somehow I think it would be good to avoid such uploads so close to the
>>> freeze or better coordinate uploads of pep8.
>>>
>>> Would it be possible to re-compile reverse build-dependencies of pep8
>>> before a new major upstream release? Somehow this feels like it should
>>> be treated like a (library) transtion.
>>
>> I don't think so.
> 
> No to what exactly?

Sorry for the confusion. I don't think that this needs to be treated as a
library transition.

If rdeps abort on pep8 errors, then maybe they shouldn't do that. Just like
using -Werror is calling for trouble. Or they need to leave with the occasional
FTBFS bug.

Cheers,
Emilio

Bug#844924: pygobject: FTBFS: Tests failures

[Michael Biebl]

Am 20.11.2016 um 02:45 schrieb Emilio Pozuelo Monfort:
> On 20/11/16 01:44, Michael Biebl wrote:
>> Am 19.11.2016 um 08:03 schrieb Lucas Nussbaum:
>>> Source: pygobject
>>> Version: 3.22.0-1
>>> Severity: serious
>>> Tags: stretch sid
>>> User: debian...@lists.debian.org
>>> Usertags: qa-ftbfs-20161118 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):
 if 'generic-c-marshaller' in GObject.features:
 ^
 pygtkcompat/pygtkcompat.py:102:1: E305 expected 2 blank lines after class 
 or function definition, found 1
 _unset = object()
 ^
>>
>> Looks like pep8 got stricter (again).
>> There were some new upstream releases just recently.
>> I got some build failures in other packages as well.
>>
>> Somehow I think it would be good to avoid such uploads so close to the
>> freeze or better coordinate uploads of pep8.
>>
>> Would it be possible to re-compile reverse build-dependencies of pep8
>> before a new major upstream release? Somehow this feels like it should
>> be treated like a (library) transtion.
> 
> I don't think so.

No to what exactly?


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



signature.asc
Description: OpenPGP digital signature

Bug#822078: debian-installer: Unbootable system after the installation on Dell XPS13 P54G model

[Cyril Brulebois]

Control: severity -1 important

Hi,

Sorry for not getting back to you sooner, your bug report didn't reach the
mailing list due to uncompressed attachments (and mail size limits)…

Ramakrishnan Muthukrishnan  (2016-04-21):
> I installed debian from a debian testing nightly iso image for amd64 on
> a Dell XPS13 laptop.
> 
> The installation went smoothly. On the first reboot, after removing the
> installation media (USB stick), the machine won't boot and complains
> that it cannot find a boot media.
> 
> I then searched the web and found similar reports and found this guide:
> 
>  
> 
> which solved the problem by first preparing a boot media using rEFInd
> and booting with it into the just installed Debian system and then
> renaming/moving certain files. Pasting the relevant instructions below:
> 
> cd /boot/efi/EFI
> cp -r debian BOOT
> mv BOOT/grubx64.efi BOOT/bootx64.efi
> 
> Is this something specific to the way Dell XPS13 bios/efi firmware
> expects? This is my first installation of Debian on a UEFI machine, so
> perhaps there were better ways out of this? But perhaps like me, there
> are other joe users new to EFI and face similar issues and then move
> away after a failed installation.
> 
> I will be glad to help with further information and any further testing
> on this machine.

Could this be another case of needing this specific option?
  
https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

Cc-ing Steve, who might know.


KiBi.


signature.asc
Description: Digital signature

Bug#845067: mutt: Crash when scrolling past the end of a message

[Sam Morris]

Package: mutt
Version: 1.7.1-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I triggered this by pressing space while at the end of a message.
Backtrace attached...

- -- Package-specific info:
NeoMutt 20161104 (1.7.1)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.8.0-1-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-11'
- --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
- --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
- --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu-
- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib
- --without-included-gettext --enable-threads=posix --libdir=/usr/lib
- --enable-nls --with-sysroot=/ --enable-clocale=gnu
- --enable-libstdcxx-debug --enable-libstdcxx-time=yes
- --with-default-libstdcxx-abi=new --enable-gnu-unique-object
- --disable-vtable-verify --enable-libmpx --enable-plugin
- --enable-default-pie --with-system-zlib --disable-browser-plugin
- --enable-java-awt=gtk --enable-gtk-cairo
- --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
- --enable-java-home
- --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
- --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
- --with-arch-directory=amd64
- --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
- --enable-multiarch --with-arch-32=i686 --with-abi=m64
- --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
- --enable-checking=release --build=x86_64-linux-gnu
- --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix
gcc version 6.2.0 20161103 (Debian 6.2.0-11) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr'
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man'
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc'
'--localstatedir=/var' '--disable-silent-rules'
'--libdir=\${prefix}/lib/x86_64-linux-gnu'
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu'
'--disable-maintainer-mode' '--disable-dependency-tracking'
'--with-mailpath=/var/mail' '--enable-compressed' '--enable-debug'
'--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap'
'--enable-smtp' '--enable-pop' '--enable-sidebar' '--enable-nntp'
'--enable-notmuch' '--disable-fmemopen' '--with-curses' '--with-gnutls'
'--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl'
'--without-gdbm' '--without-bdb' '--without-qdbm'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2
- -fdebug-prefix-map=/build/mutt-ANbwaV/mutt-1.7.1=.
- -fstack-protector-strong -Wformat -Werror=format-security'
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time
- -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2
- -fdebug-prefix-map=/build/mutt-ANbwaV/mutt-1.7.1=.
- -fstack-protector-strong -Wformat -Werror=format-security
- -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
- -SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO 
+HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR 
+HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR 
+HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK 
+USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE 
+USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR 
+USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
- -DOMAIN
MIXMASTER="mixmaster"
- -ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-kyoto-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt
patch-sensible-browser-neomutt
patch-sidebar-neomutt
patch-skip-quoted-neomutt
patch-smime-encrypt-self-neomutt
patch-status-color-neomutt
patch-timeout-neomutt
patch-tls-sni-neomutt

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomut

Bug#844924: pygobject: FTBFS: Tests failures

[Emilio Pozuelo Monfort]

On 20/11/16 01:44, Michael Biebl wrote:
> Am 19.11.2016 um 08:03 schrieb Lucas Nussbaum:
>> Source: pygobject
>> Version: 3.22.0-1
>> Severity: serious
>> Tags: stretch sid
>> User: debian...@lists.debian.org
>> Usertags: qa-ftbfs-20161118 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):
>>> if 'generic-c-marshaller' in GObject.features:
>>> ^
>>> pygtkcompat/pygtkcompat.py:102:1: E305 expected 2 blank lines after class 
>>> or function definition, found 1
>>> _unset = object()
>>> ^
> 
> Looks like pep8 got stricter (again).
> There were some new upstream releases just recently.
> I got some build failures in other packages as well.
> 
> Somehow I think it would be good to avoid such uploads so close to the
> freeze or better coordinate uploads of pep8.
> 
> Would it be possible to re-compile reverse build-dependencies of pep8
> before a new major upstream release? Somehow this feels like it should
> be treated like a (library) transtion.

I don't think so.

Emilio

Bug#844789: [Debian-science-sagemath] charpoly

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

On 20/11/16 01:14, Bill Allombert wrote:
> On Sun, Nov 20, 2016 at 12:54:29AM +, Jerome BENOIT wrote:
>> So the issue seems also related to the patch fix-gzip-stringfile which
>> was integrated in the last version of GAP.
> 
> Please make sure libgap has this patch applied. Otherwise gzip support
> does not work.

The current libgap-sage is built upon the last GAP source ball.


> 
>> In the header of the patch, we read: `We use pipes for reading gzipped 
>> files'.
>> What leads me to the question: why we do not use zlib instead ?
> 
> It would note make any difference since rewind does not work with zlib either.

Using zlib will allow to read gzip compressed file as regular file by replacing 
`read' by `gzread' (grossly speaking),
see http://www.zlib.net/manual.html#Gzip


> 
> Cheers,
>

Thanks,
Jerome
 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYMP+1AAoJED+SGaZ/NsaL3Qof/2TZSNc8g3LqQagN1Z+cntFK
JUohmMwH5OjPFT/N/N99ST8mYasnnZtI7oNqEhunM9ejkKrOGSHOO4VRBHQhwFFS
+SP4T1CmSqIUHhmDDbAX3ViEpOcjFwDHcbMl/sNeD4/U/llklpuRyAXQjQh4QG/2
RHE1ETI7NVA0lZxXiALVQf7WSqW7Ypw3pZJpMxHWvug+f2+Ki/O1WdzeDHi8/nbX
LGwkvzuz9kh9ae0hLrgRQjZH/wZAi9fISwUUt4MBPN920SSNT1N9eINTWaU4VMNR
g3Hzla/5NOYPcf2JZIGOy/UAVjtZVMeJQo5rQGkQeLwTcEm+ut92LqB1aku3NGC/
DMNNZUEJrsJBW7Lend4pS82s693RCJHcRBz129N3NwcaQL0v5i6TFAyITX9urPJL
2jfbqApcivJIo+fcrsiTHYD3YNBxOIu+AUzN774VYiHazrx+yBUmHROCKV6iA3pL
yw8r7PXjHRGSnhl7jlduH3OdxQR5I+Xjtz8co9vRADwNUpPNomCswggpegPiXWWi
Ed9bTVuPGaItPbKiwwyrMeYpZLrUYtgKniTXjR5sRC5oJ484J1zcPmbZbI4n5cBX
xKMQ/DBmpXy2rJRD1zAu5+vqHoDeLZVIGg9fe6ksz9trK1Z5wxk3DCnncq5fKwHZ
1vT4dYMgaBdxR/wpnYHcmsFTNJb21s2d7z9DhuFzDaG8dAFCOzh8MLRsALvlp2D3
HqjfIYmDNAKwrgkA9gXsBEhBJecBPRvrJ9UaVPteYK+yBonMQc+TJxY9vLdR8ta4
LQxGX/AVvna+1zJL57j0Bhv0PJ4aPOz3eLmGP0bDh5cgFywAPn34d5sBd/rW5283
05TbyOZE0AS0E8Kx8kWuxhNdRnB5J2/fMsaax8nIueYetJRAXL0X7MU4NLeEZawt
fnijyQhhpocr1dFN1fXd4hDQUUKBIZWiAd5csVbDdTZ+rhiF6Xf579m8jVX1JPGc
ELfff4fvfRnb6SE9wt0+GM9xJcFkJxLEvtYIiPR+4kaU7oHpbF+gEjUt8K51vXtq
lZD/rIJm7KXc/jLdDwEAncXIzOj1oBxQl/zteYeouHUDRmTpBgku11ZExuQAEar2
GIB8aHrGJ9gVamD/RtrPZpDh0EMreGiyhSDeYJPs5qnx0AYUHqbZk4P1ZFIaDx91
PMfzN15vwSPP5DOS6YUWT1rgmrpTebCAi0g30WfG5ITkA8gxs+o2hYQEB92+ARR7
dP8nWTt2WToJQuVkuPlW6VWUz8nTgKbYWrVlJ6VLdxBCAnrz1vOb7pyvNXOPkYp6
oNMLaXOuAvWSznxvq5Qh5HMUBbL/oWwY0Ha+qskrbfhJYOPGiaqeLcXR11iKl80=
=ev6x
-END PGP SIGNATURE-

Bug#845039: initramfs-tools: default path to initrd

[Ben Hutchings]

Control: severity -1 wishlist
Control: tag -1 - d-i
Control: tag -1 moreinfo

On Sat, 2016-11-19 at 20:18 +0200, icegood wrote:
> Package: initramfs-tools
> Version: 0.120+deb8u2
> Severity: important
> Tags: d-i
> 
> Dear Maintainer,
> 
> i've installed my kernel files to different location, e.g. /boot/debian. But 
> i found a problem that
> dpkg-reconfigure initramfs-tools doesn't allow me to change this path. So 
> i've updated
> /usr/sbin/update-initrams manually. Namely, despite BOOTDIR is defined there
> not all lines depend on it. Some of them depend on /boot/initrd...explicitly. 
>  And I also updated 
> ${STATEDIR}/${version} file. Please, apply appropriate settings to be able to 
> do those things via dpkg-reconfigure.

Boot loaders packaged for Debian expect kernel images and initramfs
files to be created directly in /boot.  Why does this system need to be
configured differently?

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing
anyway.



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

Bug#843916: debian-installer: fails to FTBFS when u-boot bits go missing

[Cyril Brulebois]

Hi,

Vagrant Cascadian  (2016-11-13):
> Apologies; I had been intending to commit the removal myself after the
> openrd testers got back to me, but testing took much longer than
> expected, and I neglected to follow-up with the removals needed for d-i.
> 
> I'll make sure with future removals to CC debian-boot if it's one of the
> targets currently supported in d-i, even if I plan to make the commits
> myself.

That would be nice!

FWIW things could have gone better on the release side anyway: d-i's build
system was letting such issues slip through…

And I could have communicated a bit more about the upcoming release anyway
(it took quite a while to get everything ready, so I can understand how
the fact we were trying to release can have escaped someone's attention…).


KiBi.


signature.asc
Description: Digital signature

Bug#844789: [Debian-science-sagemath] charpoly

[Bill Allombert]

On Sun, Nov 20, 2016 at 12:54:29AM +, Jerome BENOIT wrote:
> So the issue seems also related to the patch fix-gzip-stringfile which
> was integrated in the last version of GAP.

Please make sure libgap has this patch applied. Otherwise gzip support
does not work.

> In the header of the patch, we read: `We use pipes for reading gzipped files'.
> What leads me to the question: why we do not use zlib instead ?

It would note make any difference since rewind does not work with zlib either.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#845066: libmsgpack-dev: please release new version 2.0.0 (release 2016-06-26)

[Nick Black]

Package: libmsgpack-dev
Version: 1.4.2-4
Severity: normal

Dear Maintainer,

msgpack-c version 2.0.0 was released in June 26th of this year (2016),
and provides several useful new interfaces, including
msgpack_unpacker_next_with_size(). It would be nice if we could get a
newer build, thanks!

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

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

Versions of packages libmsgpack-dev depends on:
ii  libmsgpackc2  1.4.2-4

libmsgpack-dev recommends no packages.

Versions of packages libmsgpack-dev suggests:
pn  libmsgpack-doc  

-- no debconf information

Bug#845065: voctomix-outcasts: add Ryan Vermer to debian/copyright

[Holger Levsen]

package: voctomix-outcasts
x-debbugs-cc: ftpmas...@ftp-master.debian.org

On Sat, Nov 19, 2016 at 08:05:39PM +, Chris Lamb wrote:
> Missing attribution for Ryan Verner 
> Please fix on next upload.

will do, thanks for the splendid NEW processsing!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#844789: [Debian-science-sagemath] charpoly

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 19/11/16 18:37, Jerome BENOIT wrote:
> Hello,
> 
> On 19/11/16 17:43, Bill Allombert wrote:
>> On Sat, Nov 19, 2016 at 05:18:37AM +, Jerome BENOIT wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> Hello Forum,
>>>
>>> as a matter of fact, discarding the patch 
>>> /debian/patches/fix-compressed-six-files
>>> fixes the doctests failures related to gap (and libgap).
>>>
>>> I have just uploaded un unpatched version of gap at the deb-sci-sage 
>>> repository:
>>> please double check !
> 
>> Hello Jerome,
>> If I remove fix-compressed-six-files and rebuild the packages, then GAP
>> is unable to read compressed old-style .six files.
> 
>> For example install gap-alnuth and do
>> ?FieldByMatrices
> 
> Indeed, I can reproduce this issue on two distinct schroots, one with the 
> patch applied and one without it.

> 
> 
>> With the patch fix-compressed-six-files applied, I get
>> gap> ?FieldByMatrices
>> Help: several entries match this topic - type ?2 to get match [2]
> 
>> [1] Alnuth: FieldByMatrices
>> [2] Alnuth: FieldByMatricesNC
> 
>> With the patch removed fix-compressed-six-files, I get
> 
>> gap> ?FieldByMatrices
>> Help: no matching entry found
>> Help: 'FieldByMatrices' is currently undocumented.
>>   For details, try ?Undocumented Variables
> 
>> which is wrong.

What I meant is that I can reproduce this results.

> 
>> New-style .six files start by a comment lines so are not affected by the
>> upstream gap bug (which cause the first line to be lost, because rewind
>> does not work on pipe).
> 
First the issue on Sage also occurs for the new format (#SIXFORMAT ).
In fact, it occurs only when the manual.six is compressed: if, for debugging 
purpose,
each installed compressed manual.six is uncompressed, the doctests involving 
compressed manual.six
become successful.

So the issue seems also related to the patch fix-gzip-stringfile which was 
integrated in the last version of GAP.
In the header of the patch, we read: `We use pipes for reading gzipped files'.
What leads me to the question: why we do not use zlib instead ?

I have also noticed that Sage[Math] works in GAP `-p' mode, what is a bit 
confusing for me now. 


>> So it seems to me you need to apply fix-compressed-six-files to libgap
>> also.
> 
> The path fix-compressed-six-files does not affect libgap since it patchs only 
> a GAP Include file,
> more precisely /lib/helpbase.gi , while libgap deals with none of them.
> libgap only deals with the file in /src  [1,2]
> Second, the patches that deal with the material in /src are applied [3].
> 
> [1] 
> http://sources.debian.net/src/libgap-sage/4.8.6%2B3%2B20160327g69a66f0%2Bdsx-1/debian/get-orig-source.sh/
> [2] 
> http://sources.debian.net/src/libgap-sage/4.8.6%2B3%2B20160327g69a66f0%2Bdsx-1/debian/rules/
> [3] 
> http://sources.debian.net/src/libgap-sage/4.8.6%2B3%2B20160327g69a66f0%2Bdsx-1/debian/patches/series/
>  (the two first ones)
> 
> So now, I think that the patch fix-compressed-six-files might be improved.
> 
> But before, we must find a way to reproduce in `pure' GAP the issue 
> effectively observed within Sage.
> 
> Thanks,
> Jerome

Thanks,
Jerome


> 
> 
> 
>> Cheers,
>> Bill.
> 
> 
> 
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
> 

-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYMPRFAAoJED+SGaZ/NsaL68QgAKbzIztmMFqDhkYOjnckwTfz
G++uXy/DdOn8U/AAk2z3grz/I9pwIkJakyhr6mq4Q7TS6fjmvMl0xkTXxmkHWllU
l2NbWMFx0sLwTlM0PrTGx4fPoZgGxAT10OmiFv7ORHacaepQIR9iU6awRlL56/Hq
JzFxz3bonn/fbhDNArndTl2LWfHPE/i8Jj2TOe6R8jNI43bG+/DdlWIwSPJ9XTtJ
qc63yrs3UZuLEVSE2MZDIlCnCCIrTtvZsn3/5zd3CngMA15VDRB5yFeTAkQWl3K+
z+1wrfY0JMBEhXph1Wo5a9iU33F9ImMfnSjjM+BJ4hDsD9jlInhlOE75KhH44jMN
XDTi6G3OCnwlyRUlAeRxAgsTr7BsDQv2WKj1SxSHbZKTLGNVETLfEBiwqdA0KwOB
LcdWmzMFo0ib87XSV6+G4zTNsnkCjVfpM6MCcQwfQrpuyg11xh9U+0z2E3XUjPF0
Sfy15fh+SmfI/T/+eR8gTnNTqWmQMbuj6aUDLqab2Avs2BUruttJ6KXCDMH55DEQ
atNo0dLXy93OeLbsigAaxeSkCq6/KJscQJx7y48SLt/lPl1nwuAq9RPYxF7fZcBm
BeTLyiim669E8KVnzkoWOT9AKtAst6xK75ePnMBB9NQR8A3aomcBscIMwD35aiRc
RusxyFVeFk6wJREv7s5SPnStTMqR58Ho7h9ZAlGyGkuBAzFpNLN4YQlbXOm8VQ4S
u+U/Uwc/278bhvIli8OvXm+PjgAow86UhJhVZdhRAYJEtkQku/vOvTdHsR9zhOAS
JD/q/7IxCg94BGqZ3HqzOfpjDkU4iwglRFlOpS25OABqMDB9LwdmVqvhLwlflEkE
ulncRrEVIM2yFY4N/0Ye9HHnCDBt4LNvjuVmoDX9pMtiOb6l/2GbLUXcer4uFMWL
YYxJ1kWut9mO5+CwvvLFluvZZt1hLRi+xbisQS1/X27iYVQQolDFs+yGV+leyuFe
Ov3PvaGirqwzuv8Oc4dIUDJdrj6sHrIHSOzryuzQcTf7nD+cN1gFGu4jS2X/zOTd
Ioa8jnnQCw/gmt1Z0TLJyf+HmFv1at+FKuV/0CyRoWQ3i/4vLgEy+3iNL796/+Ks
HTXIvxP1RJZbhKpHnRt1fVa4Aj2pFlRUKjCL4qLpL62DqTXo0mBwLz36Sm6Bgd9l
ejIJQ2E/HUw914oGrUY7ZLQjbK6q/EGCle5aQJxQgU03Yz2L035i9LULgt3YsRm0
gToWoyrqvqH32IFRcvNw6LFpulsVO7AsM5hfSUHhKZMknNptgNdz852sDdWbZSLM
jmO1sjqG/NFIShI4VTm7F23liauFWKy3XvQiE413NfzYtmeZwX8sJUNeCyrt+so=
=qrJI
-END PGP SIGNATURE-

Bug#844924: pygobject: FTBFS: Tests failures

[Michael Biebl]

Am 20.11.2016 um 01:44 schrieb Michael Biebl:

> Looks like pep8 got stricter (again).
> There were some new upstream releases just recently.
> I got some build failures in other packages as well.
> 

Here is such another bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844533


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



signature.asc
Description: OpenPGP digital signature

Bug#844924: pygobject: FTBFS: Tests failures

[Michael Biebl]

Am 19.11.2016 um 08:03 schrieb Lucas Nussbaum:
> Source: pygobject
> Version: 3.22.0-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161118 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):
>> if 'generic-c-marshaller' in GObject.features:
>> ^
>> pygtkcompat/pygtkcompat.py:102:1: E305 expected 2 blank lines after class or 
>> function definition, found 1
>> _unset = object()
>> ^

Looks like pep8 got stricter (again).
There were some new upstream releases just recently.
I got some build failures in other packages as well.

Somehow I think it would be good to avoid such uploads so close to the
freeze or better coordinate uploads of pep8.

Would it be possible to re-compile reverse build-dependencies of pep8
before a new major upstream release? Somehow this feels like it should
be treated like a (library) transtion.


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



signature.asc
Description: OpenPGP digital signature

Bug#845064: linux: please enable CONFIG_GPIO_MCP23S08

[Sebastian Reichel]

Source: linux
Version: 4.7.8-1
Severity: wishlist

Please enable CONFIG_GPIO_MCP23S08 on armmp. It's
a common i2c gpio chip, that is used by me together
with a Raspberry Pi.

-- Sebastian

Bug#845063: ITP: html2canvas -- Take screenshots of webpages directly in the browser

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: html2canvas
  Version : 0.5.0~beta4
  Upstream Author : 2012-2016 Niklas von Hertzen 
* URL : https://github.com/niklasvh/html2canvas
* License : Expat
  Programming Lang: JS
  Description : Take screenshots of webpages directly in the browser

html2canvas allows you to take "screenshots" of webpages or parts of it,
directly on the users browser. The screenshot is based on the DOM and as such
may not be 100% accurate to the real representation as it does not make an
actual screenshot, but builds the screenshot based on the information
available on the page.

It renders the current page as a canvas image, by reading the DOM and the
different styles applied to the elements.

It does not require any rendering from the server, as the whole image is
created on the clients browser. However, as it is heavily dependent on the
browser, this library is not suitable to be used in nodejs. It doesn't
magically circumvent any browser content policy restrictions either, so
rendering cross-origin content will require a proxy to get the content to the
same origin.

It is still in a very experimental state, so the author doesn't recommend
using it in a production environment nor start building applications with it
yet, as there will be still major changes made.

Bug#844796: gnome-shell: FTBFS: /<>/src/tmp-introspect2qs0g0tu/.libs/ShellMenu-0.1: error while loading shared libraries: libmutter-clutter-1.0.so: cannot open shared object file: No such

[Michael Biebl]

Am 20.11.2016 um 01:02 schrieb Emilio Pozuelo Monfort:
> On 19/11/16 22:36, Michael Biebl wrote:
>> Am 19.11.2016 um 07:23 schrieb Lucas Nussbaum:
 libtool: link: gcc -fno-strict-aliasing -Wall -Wextra -Wundef 
 -Wnested-externs -Wwrite-strings -Wpointer-arith -Wmissing-declarations 
 -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls 
 -Wno-unused-parameter -Wno-missing-field-initializers 
 -Wdeclaration-after-statement -Wformat=2 -Wold-style-definition 
 -Wcast-align -Wformat-nonliteral -Wformat-security -Wsign-compare 
 -Wstrict-aliasing -Wshadow -Winline -Wpacked -Wmissing-format-attribute 
 -Wmissing-noreturn -Winit-self -Wmissing-include-dirs 
 -Wunused-but-set-variable -Warray-bounds -Wimplicit-function-declaration 
 -Wreturn-type -Wswitch-enum -Wswitch-default -Wno-error=unused-parameter 
 -Wno-error=missing-field-initializers -g -O2 
 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
 -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,defs -Wl,-O1 -o 
 test-theme test_theme-test-theme.o  -Wl,--as-needed ./.libs/libst-1.0.a 
 -lm -L/usr/lib/x86_64-linux-gnu/mutter -lmutter-clutter-1.0 
 -ljson-glib-1.0 -lwayland-egl -lwayland-client -lXi -lmutter-cogl 
 -lgmodule-2.0 -lgbm -ldrm -lwayland-server -lEGL -lXext -lXdamage -lXfixes 
 -lXcomposite -lXrandr -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 
 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 
 -lcroco-0.6 -lglib-2.0 -lxml2 -lX11 -pthread
 /<>/src/tmp-introspect2qs0g0tu/.libs/ShellMenu-0.1: error 
 while loading shared libraries: libmutter-clutter-1.0.so: cannot open 
 shared object file: No such file or directory
 Command '['/<>/src/tmp-introspect2qs0g0tu/ShellMenu-0.1', 
 '--introspect-dump=/<>/src/tmp-introspect2qs0g0tu/functions.txt,/<>/src/tmp-introspect2qs0g0tu/dump.xml']'
  returned non-zero exit status 127
 /usr/share/gobject-introspection-1.0/Makefile.introspection:155: recipe 
 for target 'ShellMenu-0.1.gir' failed
>>
>> I bet this is another duplicate of
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844227
> 
> That seems unrelated. That bug is about an issue on mips* due to a binutils 
> bug,
> but this report is about a failure on amd64.

Builds fine in a stretch chroot.
Awesome, another toolchain bug or in one of the build dependencies.

Somehow I feel the toolchain/base system has become much more brittle
over the last weeks.


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



signature.asc
Description: OpenPGP digital signature

Bug#844796: gnome-shell: FTBFS: /<>/src/tmp-introspect2qs0g0tu/.libs/ShellMenu-0.1: error while loading shared libraries: libmutter-clutter-1.0.so: cannot open shared object file: No such

[Emilio Pozuelo Monfort]

On 19/11/16 22:36, Michael Biebl wrote:
> Am 19.11.2016 um 07:23 schrieb Lucas Nussbaum:
>>> libtool: link: gcc -fno-strict-aliasing -Wall -Wextra -Wundef 
>>> -Wnested-externs -Wwrite-strings -Wpointer-arith -Wmissing-declarations 
>>> -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls 
>>> -Wno-unused-parameter -Wno-missing-field-initializers 
>>> -Wdeclaration-after-statement -Wformat=2 -Wold-style-definition 
>>> -Wcast-align -Wformat-nonliteral -Wformat-security -Wsign-compare 
>>> -Wstrict-aliasing -Wshadow -Winline -Wpacked -Wmissing-format-attribute 
>>> -Wmissing-noreturn -Winit-self -Wmissing-include-dirs 
>>> -Wunused-but-set-variable -Warray-bounds -Wimplicit-function-declaration 
>>> -Wreturn-type -Wswitch-enum -Wswitch-default -Wno-error=unused-parameter 
>>> -Wno-error=missing-field-initializers -g -O2 
>>> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
>>> -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,defs -Wl,-O1 -o 
>>> test-theme test_theme-test-theme.o  -Wl,--as-needed ./.libs/libst-1.0.a -lm 
>>> -L/usr/lib/x86_64-linux-gnu/mutter -lmutter-clutter-1.0 -ljson-glib-1.0 
>>> -lwayland-egl -lwayland-client -lXi -lmutter-cogl -lgmodule-2.0 -lgbm -ldrm 
>>> -lwayland-server -lEGL -lXext -lXdamage -lXfixes -lXcomposite -lXrandr 
>>> -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject 
>>> -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lcroco-0.6 -lglib-2.0 
>>> -lxml2 -lX11 -pthread
>>> /<>/src/tmp-introspect2qs0g0tu/.libs/ShellMenu-0.1: error 
>>> while loading shared libraries: libmutter-clutter-1.0.so: cannot open 
>>> shared object file: No such file or directory
>>> Command '['/<>/src/tmp-introspect2qs0g0tu/ShellMenu-0.1', 
>>> '--introspect-dump=/<>/src/tmp-introspect2qs0g0tu/functions.txt,/<>/src/tmp-introspect2qs0g0tu/dump.xml']'
>>>  returned non-zero exit status 127
>>> /usr/share/gobject-introspection-1.0/Makefile.introspection:155: recipe for 
>>> target 'ShellMenu-0.1.gir' failed
> 
> I bet this is another duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844227

That seems unrelated. That bug is about an issue on mips* due to a binutils bug,
but this report is about a failure on amd64.

Cheers,
Emilio

Bug#844283: needrestart: uses wrong quote function for regexps in default configuration file

[Paul Wise]

On Sat, 2016-11-19 at 23:17 +0100, Thomas Liske wrote:

> The default configuration has been fixed upstream.

Thanks, please ensure the fix reaches stretch before the freeze:

https://release.debian.org/#release-dates

I do not think that this bug should have a severity of serious

I think it should be serious for these reasons:

I was surprised that the blacklist stuff wasn't tested properly.

I was unhappy to see that Perl language features were not used correctly.

needrestart is a sysadmin tool. The audience is highly technical and
has high attention to detail. False positives in a tool like this can
cumulatively waste thousands of hours of time of one of the more
important classes of Debian users. I think this is a big problem.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#844817: [Pkg-cgit-devel] Bug#844817: cgit: FTBFS: build-dependency not installable: libssl-dev

[Peter Colberg]

Control: reassign -1 apache2-dev

Reassigning this bug to be closed in the next upload of apache2.

https://bugs.debian.org/845033#21

Peter

Bug#845033: apache2-dev: please provide separate package dh-apache2

[Stefan Fritsch]

On Saturday, 19 November 2016 18:06:44 CET Peter Colberg wrote:
> On Sat, Nov 19, 2016 at 11:58:41PM +0100, Stefan Fritsch wrote:
> > I will move the libssl-dev dependency to a new mod_ssl dev package. That
> > should avoid this issue without having to modify loads of other packages.
> 
> Thanks, that will fix the FTBFS.

Uploaded. Should be in NEW now.

> I still think it’s a good idea to separate dh-apache2 though since it
> introduces unneeded dependencies for packages that install only config
> files. I can offer to help triage packages that build modules and
> depend on dh-apache2 without depending on apache2-dev.

Maybe. I will think about it. But not today ;)

Stefan

Bug#845062: ifrench-gut: FTBFS when built with dpkg-buildpackage -A (dpkg-genbuildinfo: error: cannot fstat file ../ifrench-gut_1.0-31_amd64.deb)

[Santiago Vila]

Package: src:ifrench-gut,dpkg-dev
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-indep
debian/patches/automakehash.dpatch -patch
patching file makehash
Hunk #1 succeeded at 146 (offset 1 line).
Hunk #2 succeeded at 193 (offset 1 line).
Hunk #3 succeeded at 273 (offset 1 line).
debian/patches/autodicooption.dpatch -patch
patching file makehash
Hunk #2 succeeded at 40 (offset 1 line).
Hunk #3 succeeded at 163 (offset 1 line).
Hunk #4 succeeded at 199 (offset 1 line).
Hunk #5 succeeded at 422 (offset 1 line).
debian/patches/replacement_aff.dpatch -patch

[... snipped ...]

chercher ses dictionnaires.
Probablement : /usr/lib/ispell

(Faites de même pour ./francais-TeX8b.aff et ./francais-TeX8b.hash.)

is2my-spell.pl francais.aff > fr-pre.aff
LC_ALL=C sed -e 's/^SET.*/SET ISO8859-15/;s/^TRY.*/TRY 
aeioàéèêîâsinrtlcdugmphbyfvkwôûëöïù½/' fr-pre.aff > fr.aff
wc -l < francais.dico > francais.dico.cnt
cat francais.dico.cnt francais.dico > fr.dic
touch build-stamp
 fakeroot debian/rules binary-indep
dh_testdir
dh_testroot
dh_prep
dh_installdirs
dh_installdirs: Compatibility levels before 9 are deprecated (level 7 in use)
# Add here commands to install the package into debian/ifrench-gut.
install -m 0644 fr.aff /<>/debian/myspell-fr-gut/usr/share/hunspell
install -m 0644 fr.dic /<>/debian/myspell-fr-gut/usr/share/hunspell
# links for myspell dicts
ln -s /usr/share/hunspell/fr.aff 
/<>/debian/myspell-fr-gut/usr/share/myspell/dicts/fr.aff
ln -s /usr/share/hunspell/fr.dic 
/<>/debian/myspell-fr-gut/usr/share/myspell/dicts/fr.dic
for CC in FR BE LU CH; do for SUF in aff dic; do\
  ln -s fr.${SUF} 
/<>/debian/myspell-fr-gut/usr/share/hunspell/fr_${CC}.${SUF}; \
  ln -s /usr/share/hunspell/fr.${SUF} 
/<>/debian/myspell-fr-gut/usr/share/myspell/dicts/fr_${CC}.${SUF}; 
\
done; done
dh_testdir
dh_testroot
dh_installdocs
dh_installdocs: Compatibility levels before 9 are deprecated (level 7 in use)
dh_installchangelogs
dh_installchangelogs: Compatibility levels before 9 are deprecated (level 7 in 
use)
dh_link
installdeb-myspell -p myspell-fr-gut
dh_compress
dh_fixperms
dh_installdeb -i
dh_installdeb: Compatibility levels before 9 are deprecated (level 7 in use)
dh_gencontrol
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
dh_md5sums
dh_builddeb -i
dpkg-deb: building package 'myspell-fr-gut' in 
'../myspell-fr-gut_1.0-31_all.deb'.
 dpkg-genbuildinfo --build=all
dpkg-genbuildinfo: error: cannot fstat file ../ifrench-gut_1.0-31_amd64.deb: No 
such file or directory
dpkg-buildpackage: error: dpkg-genbuildinfo --build=all gave error exit status 2


The package does not use dpkg-genbuildinfo explicitly, so this seems
like a bug in dpkg-dev.

On the other hand, if this were a bug in dpkg-dev, I would expect to
find a lot more packages with the same problem, but I only found this
one.

So this is really strange and I don't really know where is the bug.
Please do agree on which package is to blame.

Thanks.

Bug#844646: Processed (with 1 error): Re: Bug#844646: Could not install debian with debian-testing-i386-netinst.iso 2016-11-17

[Cyril Brulebois]

Debian Bug Tracking System  (2016-11-17):
> Processing commands for cont...@bugs.debian.org:
> 
> > merge 844644 844646
> Bug #844644 [debian-installer] debian-installer: debootstrap fails with error 
> 127: line 617: : Permission denied
> Unable to merge bugs because:
> severity of #844646 is 'critical' not 'normal'
> Failed to merge 844644: Did not alter merged bugs.

It would really help if one would send BTS commands in reply to actual
bug reports so that they thread properly.

Seeing there was no reply to the bug report here, I've just -done@ it
since there were other bug reports for this, which are now closed
because the forcemerge happened outside the thread…

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844646#12


KiBi.


signature.asc
Description: Digital signature

Bug#844848: mgba: FTBFS: ld: cannot find -lncurses

[Sérgio Benjamim]

Hi,

I'll take a look next week.

sergio-br2


On 19/11/2016 04:46, Lucas Nussbaum wrote:

Source: mgba
Version: 0.4.1+dfsg1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20161118 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):

/usr/bin/cc  -fPIC -g -O2 -fdebug-prefix-map=/<>/mgba-0.4.1+dfsg1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-Wall -Wextra -std=c99 -pthread -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -shared 
-Wl,-soname,libmgba.so.0.4 -o libmgba.so.0.4.1 CMakeFiles/mgba.dir/src/arm/arm.c.o 
CMakeFiles/mgba.dir/src/arm/decoder-arm.c.o CMakeFiles/mgba.dir/src/arm/decoder-thumb.c.o 
CMakeFiles/mgba.dir/src/arm/decoder.c.o CMakeFiles/mgba.dir/src/arm/isa-arm.c.o 
CMakeFiles/mgba.dir/src/arm/isa-thumb.c.o CMakeFiles/mgba.dir/src/gba/audio.c.o 
CMakeFiles/mgba.dir/src/gba/bios.c.o CMakeFiles/mgba.dir/src/gba/cheats.c.o 
CMakeFiles/mgba.dir/src/gba/gba.c.o CMakeFiles/mgba.dir/src/gba/hardware.c.o 
CMakeFiles/mgba.dir/src/gba/hle-bios.c.o CMakeFiles/mgba.dir/src/gba/input.c.o 
CMakeFiles/mgba.dir/src/gba/io.c.o CMakeFiles/mgba.dir/src/gba/memory.c.o 
CMakeFiles/mgba.dir/src/gba/savedata.c.o CMakeFiles/mgba.dir/src/gba/serialize.c.o 
CMakeFiles/mgba.dir/src/gba/sharkport.c.o CMakeFiles/mgba.dir/src/gba/sio.c.o 
CMakeFiles/mgba.dir/src/gba/video.c.o CMakeFiles/mgba.dir/src/gba/cheats/codebreaker.c.o 
CMakeFiles/mgba.dir/src/gba/cheats/gameshark.c.o 
CMakeFiles/mgba.dir/src/gba/cheats/parv3.c.o CMakeFiles/mgba.dir/src/gba/context/config.c.o 
CMakeFiles/mgba.dir/src/gba/context/context.c.o 
CMakeFiles/mgba.dir/src/gba/context/directories.c.o 
CMakeFiles/mgba.dir/src/gba/context/overrides.c.o 
CMakeFiles/mgba.dir/src/gba/context/sync.c.o CMakeFiles/mgba.dir/src/debugger/debugger.c.o 
CMakeFiles/mgba.dir/src/debugger/memory-debugger.c.o 
CMakeFiles/mgba.dir/src/debugger/gdb-stub.c.o 
CMakeFiles/mgba.dir/src/gba/renderers/software-bg.c.o 
CMakeFiles/mgba.dir/src/gba/renderers/software-mode0.c.o 
CMakeFiles/mgba.dir/src/gba/renderers/software-obj.c.o 
CMakeFiles/mgba.dir/src/gba/renderers/video-software.c.o 
CMakeFiles/mgba.dir/src/util/circle-buffer.c.o 
CMakeFiles/mgba.dir/src/util/configuration.c.o CMakeFiles/mgba.dir/src/util/crc32.c.o 
CMakeFiles/mgba.dir/src/util/formatting.c.o CMakeFiles/mgba.dir/src/util/gui.c.o 
CMakeFiles/mgba.dir/src/util/hash.c.o CMakeFiles/mgba.dir/src/util/nointro.c.o 
CMakeFiles/mgba.dir/src/util/patch-ips.c.o CMakeFiles/mgba.dir/src/util/patch-ups.c.o 
CMakeFiles/mgba.dir/src/util/patch.c.o CMakeFiles/mgba.dir/src/util/png-io.c.o 
CMakeFiles/mgba.dir/src/util/string.c.o CMakeFiles/mgba.dir/src/util/table.c.o 
CMakeFiles/mgba.dir/src/util/vfs.c.o CMakeFiles/mgba.dir/version.c.o 
CMakeFiles/mgba.dir/src/util/vfs/vfs-mem.c.o CMakeFiles/mgba.dir/src/util/vfs/vfs-fd.c.o 
CMakeFiles/mgba.dir/src/util/vfs/vfs-dirent.c.o 
CMakeFiles/mgba.dir/src/platform/posix/memory.c.o 
CMakeFiles/mgba.dir/src/third-party/inih/ini.c.o 
CMakeFiles/mgba.dir/src/third-party/blip_buf/blip_buf.c.o 
CMakeFiles/mgba.dir/src/gba/rr/mgm.c.o CMakeFiles/mgba.dir/src/gba/rr/rr.c.o 
CMakeFiles/mgba.dir/src/gba/rr/vbm.c.o CMakeFiles/mgba.dir/src/gba/supervisor/cli.c.o 
CMakeFiles/mgba.dir/src/gba/supervisor/export.c.o 
CMakeFiles/mgba.dir/src/gba/supervisor/thread.c.o 
CMakeFiles/mgba.dir/src/platform/commandline.c.o 
CMakeFiles/mgba.dir/src/gba/sio/lockstep.c.o 
CMakeFiles/mgba.dir/src/debugger/cli-debugger.c.o 
CMakeFiles/mgba.dir/src/debugger/parser.c.o 
CMakeFiles/mgba.dir/src/platform/ffmpeg/ffmpeg-encoder.c.o 
CMakeFiles/mgba.dir/src/platform/imagemagick/imagemagick-gif-encoder.c.o 
CMakeFiles/mgba.dir/src/util/vfs/vfs-zip.c.o CMakeFiles/mgba.dir/src/util/vfs/vfs-lzma.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zAlloc.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zArcIn.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zBuf.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zBuf2.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zCrc.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zCrcOpt.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zDec.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/CpuArch.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Delta.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/LzmaDec.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Lzma2Dec.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Bra.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Bra86.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/BraIA64.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Bcj2.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Ppmd7.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/Ppmd7Dec.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zFile.c.o 
CMakeFiles/mgba.dir/src/third-party/lzma/7zStream.c.o -ledit -lncurses -lbsd -lavcodec 
-lavformat -lavresample -lavutil -lswscale -lMagickWand-6.Q16 -lMagickCore-6.Q16 -lz -lpng 
-lz -lz -lzip -lz -lm -lpng -lz

Bug#845061: yasnippet: Broken with emacs25

[Sean Whitton]

Package: yasnippet
Version: 0.9.0~beta1-5
Severity: important

Dear maintainer,

yasnippet is broken with emacs25.  A sampling of errors from *Messages*:

Error while loading 50yasnippet: Wrong type argument: integerp, nil

yas--define-snippets-1: Wrong type argument: integerp, nil

Error in post-command-hook (yas-global-mode-check-buffers): 
(wrong-type-argument integerp nil)

emacs24 might not be included in stretch, so this bug has the potential
to become release-critical.  It would be great to see an updated
yasnippet (ideally including a fix for #818440).

Thanks!

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

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#844641: debian-installer: message about security erase does not wrap, loosing essential part at end

[Cyril Brulebois]

Control: reassign -1 partman-crypto

Jonas Smedegaard  (2016-11-17):
> Package: debian-installer
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On weekly snapshot of Stretch netinst image downloaded today, choosing
> an install in danish with full disk encryption, I notice that at the
> screen informing about the many hour long security wipe of the target
> disk the message below the bar is not wrapped - and (at least in danish)
> the important part of the message is cut off:
> 
>  "... Dette trin kan springes over ved a"
> 
> In english: "... This step can be skipped b"

For the sake of completeness:

,---[ debian/po/da.po ]---
| #. Type: text
| #. Description
| #. :sl3:
| #: ../partman-crypto.templates:24001
| msgid ""
| "The installer is now overwriting ${DEVICE} with zeroes to delete its "
| "previous contents. This step may be skipped by cancelling this action."
| msgstr ""
| "Installationsprogrammet overskriver nu ${DEVICE} med nul-tegn for at slette "
| "det tidligere indhold. Dette trin kan udelades ved at afbryde denne 
handling."
`---

,---[ debian/partman-crypto.templates ]---
| Template: partman-crypto/progress/plain_erase_text
| Type: text
| # :sl3:
| _Description: The installer is now overwriting ${DEVICE} with zeroes to 
delete its previous contents. This step may be skipped by cancelling this 
action.
`---

I think it's used here:
,---[ lib/crypto-base.sh ]---
| crypto_do_wipe () {
| local template dev fifo pid x
| template=$1
| dev=$2
| fifo=/var/run/wipe_progress
| 
| mknod $fifo p
| /bin/blockdev-wipe -s $((512*1024)) $dev > $fifo &
| pid=$!
| 
| cancelled=0
| db_capb backup align progresscancel
| db_progress START 0 1000 ${template}_title
| db_progress INFO ${template}_text
| while read x <&9; do
| db_progress STEP 1
| if [ $? -eq 30 ]; then
| cancelled=1
| kill $pid
| break
| fi
| done 9< $fifo
| db_progress STOP
| db_capb backup align
| […]
`---

I can't tell for sure whether it's used properly and/or whether it's
just that the current progress bar implementation isn't supposed to
allow for wrapping.


KiBi.


signature.asc
Description: Digital signature

Bug#844579: console-setup: CyrAsia font missing Kazakh letter

[Cyril Brulebois]

Hi,

Baurzhan Muftakhidinov  (2016-11-17):
> Package: console-setup
> 
> Version: 1.153
> 
> Dear maintainers,
> 
> Recently I loaded CyrAsia font in console, and have noticed
> that it misses one Kazakh letter:
> 
> Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke
> ұ U+04B1 Cyrillic Small Letter Straight U with Stroke
> 
> I checked these codes in
> https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/Fonts/fontsets/CyrAsia.256
> 
> Could you please add these to CyrAsia font definition?

I'm not sure what's involved to add support for those. Maybe it's
sufficient to add two lines with the codepoint to the file you
mentioned?

Maybe you could try patching console-setup locally and reporting back
whether that fixed the bug?


KiBi.


signature.asc
Description: Digital signature

Bug#845060: lxpanel: FTBFS on !linux archs

[Pino Toscano]

Source: lxpanel
Version: 0.9.0-1
Severity: important
Tags: patch
Control: forwarded -1 https://sourceforge.net/p/lxde/patches/537/

Hi,

lxpanel 0.9.0 fails to compile on kFreeBSD[1][2] and Hurd[3].

The issue is mostly upstream, which I just reported [4] (a copy of the
patch is attached for reference).
An additional change for the Debian packaging is making sure that ALSA
is always disabled for non-Linux architectures (so alternative
implementations of libasound2 are not used, since not complete enough).

[1] 
https://buildd.debian.org/status/fetch.php?pkg=lxpanel&arch=kfreebsd-amd64&ver=0.9.0-1&stamp=1479593591
[2] 
https://buildd.debian.org/status/fetch.php?pkg=lxpanel&arch=kfreebsd-i386&ver=0.9.0-1&stamp=1479594452
[3] 
https://buildd.debian.org/status/fetch.php?pkg=lxpanel&arch=hurd-i386&ver=0.9.0-1&stamp=1479593695
[4] https://sourceforge.net/p/lxde/patches/537/

Thanks,
-- 
Pino
--- a/plugins/volumealsa/volumealsa.c
+++ b/plugins/volumealsa/volumealsa.c
@@ -1333,8 +1333,8 @@ static GtkWidget *volumealsa_configure(L
 GtkTreeIter iter;
 int active = 0;
 int i = 0;
-#ifndef DISABLE_ALSA
 int j = -1;
+#ifndef DISABLE_ALSA
 
 snd_mixer_selem_id_alloca(&sid);
 /* setup card selector */
--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,7 @@ ifeq ($(DEB_HOST_ARCH_OS),linux)
 	dh_auto_configure -- --with-plugins=all --disable-silent-rules
 else
 	# omit netstat plugin on non-linux, requires wireless-tools
-	dh_auto_configure -- --with-plugins=all,-netstat --disable-silent-rules
+	dh_auto_configure -- --with-plugins=all,-netstat --disable-silent-rules --disable-alsa
 endif
 
 override_dh_strip:

Bug#843890: Monitoring child processes

[Jesse Smith]

I am working on new code for cpulimit which will allow the children of
target processes to be monitored. The feature can be invoked using the
"-m" or "--monitor-forks" flag on the command line.

While I'm still in the early testing stages of this and working to make
the code cross-platform, you can test it now if you like by downloading
the development snapshot here:
http://resonatingmedia.com/cpulimit/cpulimit-2.4.tar.gz

An example of the command in action might be

cpulimit -l 25 -m -- my-exectuable

The above command launches my-executable, limits its CPU usage to 25%
and monitors any children spawned, also limiting them to 25% usage. If
the target process's children also spawn children, those too are
monitored. Which means the user needs to be very careful not to limit a
core process like init as it could bring every process on the system to
a crawl.

For reasons I hope are obvious, if the target spawns a lot of processes,
cpulimit will become decreasingly effective due to the increased demands
of monitoring not only more processes, but watching their children too.

When the target process dies, but child processes are still running,
cpulimit should continue to monitor and throttle the child processes
until they too exit.

Again, this is a testing snapshot. It seems to be working okay for me on
Debian, but I still need to make sure the code compiles and works on
other platforms. If I don't get any bug reports, I'm finish my tweaks
and then publish the new 2.4 version on the LimitCPU website.

Jesse

Bug#845058: [Pkg-fonts-devel] Bug#845058: fonts-noto: Installing the package freezes all graphical applications.

[Norbert Preining]

On Sat, 19 Nov 2016, Valentin Lorentz wrote:
> killall fc-cache

fc-cache might run for quite some time and occupy lots of resources.
I suggest updating the cache once before installing the fonts with
fc-cache -fs
(as root!), and then installing the font while not being logged in,
or mousepad has been closed.

Norbert

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

Bug#845033: apache2-dev: please provide separate package dh-apache2

[Peter Colberg]

On Sat, Nov 19, 2016 at 11:58:41PM +0100, Stefan Fritsch wrote:
> I will move the libssl-dev dependency to a new mod_ssl dev package. That 
> should avoid this issue without having to modify loads of other packages.

Thanks, that will fix the FTBFS.

I still think it’s a good idea to separate dh-apache2 though since it
introduces unneeded dependencies for packages that install only config
files. I can offer to help triage packages that build modules and
depend on dh-apache2 without depending on apache2-dev.

Peter

Bug#845059: python-fuse: Please provide a debug package

[Celelibi]

Package: python-fuse
Version: 2:0.2.1-14
Severity: wishlist

Dear maintainer,

I was experiencing some surprising behavior with python-fuse and decided
to trace the function calls with gdb. Python and fuse both have a dbg
package, but python-fuse doesn't.

Please consider adding a package with the debug symbols, the same way
there is one for python-llfuse.

Thanks in advance.

Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-fuse depends on:
ii  fuse  2.9.7-1
ii  libc6 2.24-5
ii  libfuse2  2.9.7-1

python-fuse recommends no packages.

python-fuse suggests no packages.

-- no debconf information

Bug#828545: simutrans: FTBFS with openssl 1.1.0

[Markus Koschany]

On 19.11.2016 23:58, James Cowgill wrote:
> On 19/11/16 14:04, Jörg Frings-Fürst wrote:
>> severity 828353 important
>> unblock 827061 by 828353
>> thanks
>>
>> we removed all openssl dependnecy so I'm downgrading and unblock this
>> bug.
> 
> I disagree. The version of simutrans in testing is still RC-buggy so
> this bug should still be severity serious.
> 
> James

Hi,

I agree with James here. I think we don't need to downgrade the severity
of the bug because the package will automatically migrate to testing and
then the issue will be resolved anyway. Do I miss something?

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#844643: ITP: flatcam -- 2D Computer-Aided PCB Manufacturing on a CNC router

[Simon Richter]

Hi,

On 17.11.2016 19:33, Carsten Schoenert wrote:

> * Package name: flatcam

> I'd like to place this package into the pkg-electronics team as other PCB
> related package are workend on there. I will need a sponsor.

In case there are no other sponsors, I could do it, but please treat
this as a last resort as I often have long stretches where I don't even
find time to go online.

   Simon




signature.asc
Description: OpenPGP digital signature

Bug#845058: fonts-noto: Installing the package freezes all graphical applications.

[Valentin Lorentz]

Package: fonts-noto
Version: 20160724-3
Severity: critical

Dear Maintainer,

Installing fonts-noto on my computer leads to *all* of my graphic
applications to enter an infinite loop, using all my CPU cores, and
blocking aptitude. This persists until I stop aptitude and remove
fonts-noto.


Here is how to reproduce this bug, and to unfreeze the system (please
read the full mail before running the second command):

First, make sure related packages are uninstalled:

aptitude remove fonts-noto fonts-noto-cjk fonts-noto-hinted
fonts-noto-unhinted

Then, install them:

aptitude install fonts-noto

Before aptitude ends, all graphic apps freeze/loop, so you have to
switch to a TTY.
Running strace on one of the affected processes (mousepad) shows it is
in a loop reading /usr/share/fonts/opentype/noto/NotoSansCJK-DemiLight.ttc.

aptitude is currently hanging because of a fontconfig trigger calling
fc-cache, which does not terminate. You have to kill it to make aptitude
end:

killall fc-cache

Aptitude now ends gracefully, and tells us that fc-cache crashed, but
there is more information in /var/log/fontconfig.log. However, this file
only contains “Terminated.”.

ll graphical apps are still frozen. You have to uninstall the fonts to
unfreeze them:

aptitude remove fonts-noto fonts-noto-cjk fonts-noto-hinted
fonts-noto-unhinted

(This aptitude will run slowly, because the CPU is fully used by other
processes.)

Graphic apps should now be unfrozen.

Reinstalling fonts-noto at this point re-freezes them. I tried this half
a dozen time to write this bug report, it behaved exactly like this
every time.



fontconfig version: 2.11.0-6.7
Desktop environment: xfce4 (4.12.3) (in case this is relevant)


Best regards,
Valentin



signature.asc
Description: OpenPGP digital signature

Bug#828545: simutrans: FTBFS with openssl 1.1.0

[James Cowgill]

On 19/11/16 14:04, Jörg Frings-Fürst wrote:
> severity 828353 important
> unblock 827061 by 828353
> thanks
> 
> we removed all openssl dependnecy so I'm downgrading and unblock this
> bug.

I disagree. The version of simutrans in testing is still RC-buggy so
this bug should still be severity serious.

James



signature.asc
Description: OpenPGP digital signature

Bug#845033: apache2-dev: please provide separate package dh-apache2

[Stefan Fritsch]

On Saturday, 19 November 2016 12:39:18 CET Peter Colberg wrote:
> apache2-dev was changed to depend on libssl1.0-dev | libssl-dev (<< 1.1)
> recently (#844160), which has caused a FTBFS in cgit that depends on
> libssl-dev without a version constraint.
> 
> I would rather not constrain cgit’s build-depends to OpenSSL 1.0,
> since it needs apache2-dev only to install an apache2 config file
> using dh_apache2. Could you provide a separate package dh-apache2?

I will move the libssl-dev dependency to a new mod_ssl dev package. That 
should avoid this issue without having to modify loads of other packages.

Cheers,
Stefan

Bug#817277: phantomjs: PhantomJS fails to run headless

[Ximin Luo]

There is more information here:

https://github.com/ariya/phantomjs/issues/14240

"If you compiled PhantomJS with X11 enabled, it will use XCB (X11) platform in 
runtime, which is not supported in headless environment. Instead of that you 
must build PhantomJS without X11 headers (dev packages installed)"

Perhaps one solution would be to have the Debian QT/Webkit package offer a 
headless version, that this phantomjs package could link against?

X

Stéphane Railhet wrote:
> Thanks about this explanation, hope this will be solved by upstream in 
> future releases.
> 
> Best Regards,
> 
> Stéphane Railhet
> > On Wednesday, 9 March 2016 6:35:08 PM AEDT Stéphane Railhet wrote:
> >> PhantomJS cannot run if there is no X server available whereas it should be
> >> able to work headless since version 1.5.
> > Unfortunately it can not be fixed in Debian. To achieve headless-ness
> > upstream statically link with customised QT + Webkit. We don't want to ship
> > forks of those projects. It would be great to eventually convince upstream 
> > to
> > use standard libraries.
> >
> > Meanwhile you can use "xvfb-run" from "xvfb" package.
> >
> > I'll update README.Debian to include a note about that.
> >
> 
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#803713: Elasticsearch should not be part of a Debian release

[Emmanuel Bourg]

Hi Hilko,

Do you think elasticsearch should be removed from unstable?

Emmanuel Bourg

Bug#844931: python-dugong: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13

[Scott Kitterman]

Control: reassign 844931 python3.5

Python3 is essentially a metapackage and contains none of the relevant code.  
You want python3.5.

Scott K

On Sat, 19 Nov 2016 14:15:52 -0800 Nikolaus Rath  wrote:
> Control: reassign 844931 python3
> Control: affects 844931 +python-dugong
> thanks
> 
> I think this is actually a bug in Python 3 - and might be caused by the
> recent OpenSSL transition.
> 
> Unless I'm mistaken, reading from an SSLSocket should not raise OSErrors
> with errno 0. For example:
> 
> 
> >>   File "/usr/lib/python3.5/ssl.py", line 937, in recv_into
> >> return self.read(nbytes, buffer)
> >>   File "/usr/lib/python3.5/ssl.py", line 799, in read
> >> return self._sslobj.read(len, buffer)
> >>   File "/usr/lib/python3.5/ssl.py", line 583, in read
> >> v = self._sslobj.read(len, buffer)
> >> OSError: [Errno 0] Error
> >>   File "/usr/lib/python3.5/socket.py", line 576, in readinto
> >> return self._sock.recv_into(b)
> 
> and
> 
> >>   File "/<>/python-dugong-3.7+dfsg/test/test_dugong.py", line 
> >> 1096, in handle
> >> return super().handle()
> >>   File "/usr/lib/python3.5/http/server.py", line 424, in handle
> >> self.handle_one_request()
> >>   File "/usr/lib/python3.5/http/server.py", line 390, in handle_one_request
> >> self.raw_requestline = self.rfile.readline(65537)
> >>   File "/usr/lib/python3.5/socket.py", line 576, in readinto
> >> return self._sock.recv_into(b)
> >>   File "/usr/lib/python3.5/ssl.py", line 937, in recv_into
> >> return self.read(nbytes, buffer)
> >> Traceback (most recent call last):
> >>   File "/usr/lib/python3.5/ssl.py", line 799, in read
> >> return self._sslobj.read(len, buffer)
> >>   File "/usr/lib/python3.5/ssl.py", line 583, in read
> >> v = self._sslobj.read(len, buffer)
> 
> 
> Best,
> -Nikolaus
> -- 
> GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
> Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
> 
>  »Time flies like an arrow, fruit flies like a Banana.«
> 
> 

Bug#828921: Fixed?

[Arnout Engelen]

forwarded 828921 https://github.com/raboof/nethogs/issues/18
tags 828921 fixed-upstream
thanks

This was already reported upstream and should be fixed since 0.8.5!


Kind regards,

Arnout

Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'

[Matthias Klose]

On 19.11.2016 22:54, Santiago Vila wrote:
> On Sat, 19 Nov 2016, Matthias Klose wrote:
> 
>> On 19.11.2016 07:40, Lucas Nussbaum wrote:
>>> Source: gcc-5
>>> Version: 5.4.1-3
>>> Severity: serious
>>> Tags: stretch sid
>>> User: debian...@lists.debian.org
>>> Usertags: qa-ftbfs-20161118 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):
>>
>> no, not the relevant part (you get it by searching for "unfinished":
>>
>> The bug is not reproducible, so it is likely a hardware or OS problem.
>> Makefile:1077: recipe for target 'reload1.o' failed
>> make[5]: *** [reload1.o] Error 1
>> make[5]: *** Waiting for unfinished jobs
>>
>> closing, that's an issue with the environment.
> 
> It's unlikely a hardware problem because the build was made in a
> virtual machine and the build was tried twice. This is written
> in the bug report itself.
> 
> This is a lot more likely to be a bug which happens randomly,
> for example, a bug in the Makefile.
> 
> Such bugs *do* exist, just see
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096
> 
> for a very simple example.
> 
> 
> In this case, there is absolutely zero evidence that it's a hardware
> problem and not a bug which happens randomly.
> 
> Do you always close bugs which happen randomly just because you can't
> reproduce them yourself, or can you acknowledge the fact that not all
> packages either always build or always fail?
> 
> (I can give a lot more examples of packages which fail to build
> randomly if you are interested).

it might not be "hardware" problem, but with all this "virtual overhead" a
corruption with some file system or something else.  Yes, I intend to close such
bug reports, because GCC itself retries to build these files, and apparently it
succeeded to build it (or else you wouldn't see this message).  That might be a
real bug, but then GCC is the wrong package to file a bug report for.

Matthias

Bug#143297: Problems with item delivery, n.9835841

[FedEx International Ground]

This is a multi-part message in MIME format.
Hello,
We could not deliver your parcel. Delivery Label is attached to this email.
Germaine Zeitlin - Area Manager FedEx , CA
Kind regards


FedEx.doc
Description: MS-Word document

Bug#845042: openssh-server: Generates invalid ecdsa host keys

[Santiago Vila]

On Sat, Nov 19, 2016 at 08:05:15PM +, Colin Watson wrote:
> On Sat, Nov 19, 2016 at 07:37:54PM +0100, Santiago Vila wrote:
> > On some systems, openssh-server postinst fails to generate correct
> > ECDSA host keys:
> [...]
> > ecdsa-sha2-nistp256 
> > E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBKXa7AmJqSutzd/0xiKpHUb9Od0FZmGBOW7CowUItSeoa2Y7mz/K5V/PLUy6Xr/pxcMvIVMIwR4dt67ZPxSobHk=
> >  root@mymachine
> 
> It appears to be a problem with reading (and fingerprinting) the public
> key rather than with generating it, perhaps?  At least, if I save that
> public key to bad-ecdsa.pub and run "ssh-keygen -l -f ./bad-ecdsa.pub"
> here, it seems quite happy with it.  That suggests that the output of
> "ssh-keygen -vvv -l -f /etc/ssh/ssh_host_ecdsa_key.pub" on a system that
> doesn't work would be of some use, perhaps under valgrind.

The machine where it happens is a QEMU/KVM virtual machine. I believed
this to be a bug in ssh because downgrading to the jessie version
fixed the issue, but now I'm not sure.

In the same machine another weird thing happens: disk I/O performance
is radically worse than the host (native) system.

I'll try to investigate a little bit more.

Thanks.

Bug#844283: needrestart: uses wrong quote function for regexps in default configuration file

[Thomas Liske]

severity 844283 normal
tags 844283 upstream fixed-upstream
thanks


Hi Paul,


thanks for the hint. Interestingly it seems that q() is somehow working
- at least if there is no EOL marker '$' in use (see also the
attachment). So the broken default config was there since the beginning
but it was not recorgnized since most of the regex did work, although
the quotation was broken. The default configuration has been fixed
upstream.

I do not think that this bug should have a severity of serious since it
is only a bug in the config file which breaks some of the
regex. Although this makes needrestart report some false positives it
does not break functionality nor security.


HTH,
Tho-facepalming-mas




Paul Wise  writes:

> Package: needrestart
> Version: 2.10-1
> Severity: serious
>
> needrestart uses the wrong Perl quote function for regexps in
> configuration file. It is using q but should be using qr
> (quote regexps). This means that all of the regexp options are
> potentially broken, but blacklist_mappings definitely is:
>
> http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators
> http://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators
>
> # checkrestart -v
> Found 0 processes using old versions of upgraded files
> # needrestart -v
> [main] eval /etc/needrestart/needrestart.conf
> [main] running in root-mode
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> ...
> [main] #27891 uses deleted /run/user/1000/orcexec.OVkLUB
> [main] #27891 is not a child
> ...
> [main] #27891 exe => /usr/bin/pulseaudio
> [main] #27891 part of user session: uid=1000 sess=17
> ...
> User sessions running outdated binaries:
>  pabs @ session #17: pulseaudio[27891]
> ...
> # lsof -p 27891 | grep orc
> pulseaudi 27891 pabs  DEL   REG   0,43253423 
> /run/user/1000/orcexec.OVkLUB
> pulseaudi 27891 pabs  mem   REG  253,1   517176 26870717 
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> # grep orc /proc/27891/maps
> 7fe19801-7fe19802 rw-s  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> 7fe19802-7fe19803 r-xs  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> 7fe19b5eb000-7fe19b664000 r-xp  fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> 7fe19b664000-7fe19b863000 ---p 00079000 fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> 7fe19b863000-7fe19b865000 r--p 00078000 fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> 7fe19b865000-7fe19b869000 rw-p 0007a000 fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> # grep -r orc /etc/needrestart/
> /etc/needrestart/needrestart.conf:q(/orcexec\.[\w\d]+( \(deleted\))?$),
> # grep -P '/orcexec\.[\w\d]+( \(deleted\))?$' /proc/27891/maps
> 7fe19801-7fe19802 rw-s  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> 7fe19802-7fe19803 r-xs  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> # cat test.pl 
> my %nrconf;
> my $pid = '27891';
> $nrconf{blacklist_mappings_q} = [q(/orcexec\.[\w\d]+( \(deleted\))?$),];
> $nrconf{blacklist_mappings_qr} = [qr(/orcexec\.[\w\d]+( \(deleted\))?$),];
> if(open(HMAP, '<', "/proc/$pid/maps")) {
>   while() {
>   chomp;
>   my ($maddr, $mperm, $moffset, $mdev, $minode, $path) = 
> split(/\s+/, $_, 6);
>   if ($path =~ /orc/){
>   print "Path: $path";
>   print " blacklisted_q" if(scalar grep { $path =~ $_; } 
> @{$nrconf{blacklist_mappings_q}});
>   print " blacklisted_qr" if(scalar grep { $path =~ $_; } 
> @{$nrconf{blacklist_mappings_qr}});
>   print "\n";
>   }
>   }
> }
> # perl test.pl
> Path: /run/user/1000/orcexec.OVkLUB (deleted) blacklisted_qr
> Path: /run/user/1000/orcexec.OVkLUB (deleted) blacklisted_qr
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> # sed -n /orc/p /etc/needrestart/needrestart.conf
> q(/orcexec\.[\w\d]+( \(deleted\))?$),
> # sed -i '/orc/s/q/qr/' /etc/needrestart/needrestart.conf
> # sed -n /orc/p /etc/needrestart/needrestart.conf
> qr(/orcexec\.[\w\d]+( \(deleted\))?$),
> # needrestart -v
> [main] eval /etc/needrestart/needrestart.conf
> [main] running in root-mode
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> ...
> No user sessions are running outdated binaries.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> '

Bug#844931: python-dugong: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13

[Nikolaus Rath]

Control: reassign 844931 python3
Control: affects 844931 +python-dugong
thanks

I think this is actually a bug in Python 3 - and might be caused by the
recent OpenSSL transition.

Unless I'm mistaken, reading from an SSLSocket should not raise OSErrors
with errno 0. For example:


>>   File "/usr/lib/python3.5/ssl.py", line 937, in recv_into
>> return self.read(nbytes, buffer)
>>   File "/usr/lib/python3.5/ssl.py", line 799, in read
>> return self._sslobj.read(len, buffer)
>>   File "/usr/lib/python3.5/ssl.py", line 583, in read
>> v = self._sslobj.read(len, buffer)
>> OSError: [Errno 0] Error
>>   File "/usr/lib/python3.5/socket.py", line 576, in readinto
>> return self._sock.recv_into(b)

and

>>   File "/<>/python-dugong-3.7+dfsg/test/test_dugong.py", line 
>> 1096, in handle
>> return super().handle()
>>   File "/usr/lib/python3.5/http/server.py", line 424, in handle
>> self.handle_one_request()
>>   File "/usr/lib/python3.5/http/server.py", line 390, in handle_one_request
>> self.raw_requestline = self.rfile.readline(65537)
>>   File "/usr/lib/python3.5/socket.py", line 576, in readinto
>> return self._sock.recv_into(b)
>>   File "/usr/lib/python3.5/ssl.py", line 937, in recv_into
>> return self.read(nbytes, buffer)
>> Traceback (most recent call last):
>>   File "/usr/lib/python3.5/ssl.py", line 799, in read
>> return self._sslobj.read(len, buffer)
>>   File "/usr/lib/python3.5/ssl.py", line 583, in read
>> v = self._sslobj.read(len, buffer)


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

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

Bug#845057: RM: golang-dns -- RoQA; binary package now built by golang-github-miekg-dns

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The golang-dns source package has been renamed to golang-github-miekg-dns,
and golang-dns-dev is now built from golang-github-miekg-dns.

Please remove the golang-dns source package.

Please do NOT remove any binary packages.

Thanks

Bug#845035: dillo: configure does not find libssl, builds without OpenSSL support

[Axel Beckert]

Hi Hilko,

Hilko Bengen wrote:
> after searching for "AC_CHECK_LIB(ssl, SSL_library_init" using
> codesearch.debian.net and rebuilding with OpenSSL 1.1, I found that the
> OpenSSL is no longer detected and thus no longer used when building the
> package.
[…]
> Something like the following should be enough to fix the OpenSSL
> detection. However, there may be other changes necessary due to the
> changed API in OpenSSL 1.1.
> 
> -   AC_CHECK_LIB(ssl, SSL_library_init, [
> +   AC_CHECK_LIB(ssl, SSL_new, [

Thanks for the notice and the preliminary patch!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Daniel Shahaf]

Bart Schaefer wrote on Sat, Nov 19, 2016 at 10:00:23 -0800:
> On Nov 19,  7:55am, Daniel Shahaf wrote:
> } Subject: Re: Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrecti
> }
> } Martin Steigerwald wrote on Fri, Nov 18, 2016 at 14:15:51 +0100:
> } > So two fixes to consider:
> } > 
> } > 1) Don't confirm on space, as thats to easy to trigger accidentally. :)
> } 
> } The code confirms on both tabs (since commit 7f1ce570) and spaces (since
> } before CVS).  Does anyone know a reason for doing this?
> 
> If you have a look at the zsh-workers article referenced by 7f1ce570,
> you'll see that both space and tab date from time immemorial; the patch
> in 7f1ce570 actually REMOVES the interpretation of tab as "yes" from
> the NO_RM_STAR_SILENT option, it didn't change CORRECT handling.
> 

I had looked at it, but missummarized it.  Mea culpa.

> Why it's this way probably has more to do with Paul Falstad's typing
> habits than anything else.  If you're used to hitting space or tab at
> a completion, and most of the time you believe the correction, then
> you probably want space and tab to mean "go ahead" anytime the shell
> is waiting for something.
> 
> Notice the RM_STAR_WAIT option for a similar situation.
> 
> While I don't use CORRECT and therefore personally don't much care
> what this prompt does, I question whether one person remarking about
> this after 25+ years of it being the way it has been, is a sufficient
> reason for us to immediately change it.

I didn't write the patch because a guy on the internet suggested it.
I wrote the patch because the semantics of tab and space at that point
are undocumented and I had been convinced by the argument that using
space to accept a correction violates the principle of least surprise.

If we do keep space and tab then we should document them.  

Daniel

Bug#844855: gcc-5: FTBFS: conftest.c:136: undefined reference to `setproctitle'

[Santiago Vila]

On Sat, 19 Nov 2016, Matthias Klose wrote:

> On 19.11.2016 07:40, Lucas Nussbaum wrote:
> > Source: gcc-5
> > Version: 5.4.1-3
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20161118 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):
> 
> no, not the relevant part (you get it by searching for "unfinished":
> 
> The bug is not reproducible, so it is likely a hardware or OS problem.
> Makefile:1077: recipe for target 'reload1.o' failed
> make[5]: *** [reload1.o] Error 1
> make[5]: *** Waiting for unfinished jobs
> 
> closing, that's an issue with the environment.

It's unlikely a hardware problem because the build was made in a
virtual machine and the build was tried twice. This is written
in the bug report itself.

This is a lot more likely to be a bug which happens randomly,
for example, a bug in the Makefile.

Such bugs *do* exist, just see

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

for a very simple example.


In this case, there is absolutely zero evidence that it's a hardware
problem and not a bug which happens randomly.

Do you always close bugs which happen randomly just because you can't
reproduce them yourself, or can you acknowledge the fact that not all
packages either always build or always fail?

(I can give a lot more examples of packages which fail to build
randomly if you are interested).

Thanks.

Bug#845056: libica FTBFS

[Adrian Bunk]

Source: libica
Version: 2.6.1-3
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=libica&arch=s390x&ver=2.6.1-3&stamp=1473526527

...
cd src/tests && LD_LIBRARY_PATH=/«PKGBUILDDIR»/src/.libs 
PATH=/«PKGBUILDDIR»/src:$PATH ./suite.run silent
Starting libica test suite ...
-- (0%)
./suite.run: line 12: 19485 Illegal instruction ./icastats_test $silent
#- (2%)
./suite.run: line 14: 19486 Illegal instruction ./libica_3des_cbc_test 
$silent
debian/rules:15: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 132
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:3: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Bug#845055: markdown: please make the output reproducible

[Chris Lamb]

Source: markdown
Version: 1.0.1-8
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that markdown generates non-reproducible output.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/Markdown.pl b/Markdown.pl
index cc52c66..9264381 100755
--- a/Markdown.pl
+++ b/Markdown.pl
@@ -1208,7 +1208,7 @@ sub _EncodeEmailAddress {
 
my $addr = shift;
 
-   srand;
+   srand ($ENV{SOURCE_DATE_EPOCH} || time);
my @encode = (
sub { '&#' . ord(shift)   . ';' },
sub { '&#x' . sprintf( "%X", ord(shift) ) . ';' },

Bug#823186: chromium 53 crash

[Igor]

I have the same issue with "Aw, snap" on all sites which were mentioned
on this tread.

Here is topic which I have created
https://bugs.chromium.org/p/chromium/issues/detail?id=662751&can=2&start=0&num=100&q=snap&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce the problem:
1. go to skyeng.ru
2. after page loading I have the message Aw, Snap
3. 

What is the expected behavior?
I'm expected that the page will open without any issue

What went wrong?
I don't know

Crashed report ID: no

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? Yes Chromium 51, Chrome 48

Chrome version: 53.0.2785.143  Channel: n/a
OS Version: debian stretch, kernel 4.7 also 4.2
Flash Version: 

here is details from console

dpkg -l | grep chromium
ii  chromium  53.0.2785.143-1 
i386 web browser

details of page crash
http://paste.ubuntu.com/23438805/

Bug#838858: firmware-amd-graphics: missing SI/CI smc firmware files

[James Lu]

Control: merge 838858 843061
Control: tags 838858 + patch

Hi everyone,

I recently upgraded to the 4.8 kernel in Stretch and was hit by this as
well.

The problem seems to be that firmware-amd-graphics doesn't ship the
required radeon/*_k_smc.bin binaries at all. The attached patch adds
these to the build system, and fixes this problem, at least for me.

Best,
James
From 0386d70cb8f490bd4dfa3cfa26e58a6e57569cb2 Mon Sep 17 00:00:00 2001
From: James Lu 
Date: Sat, 19 Nov 2016 13:26:34 -0800
Subject: [PATCH] Ship SI/CI smc firmware files (radeon/*_k_smc.bin)

Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838858
---
 debian/config/amd-graphics/defines | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/config/amd-graphics/defines b/debian/config/amd-graphics/defines
index e727494..7ab6785 100644
--- a/debian/config/amd-graphics/defines
+++ b/debian/config/amd-graphics/defines
@@ -321,6 +321,13 @@ files:
  radeon/VERDE_rlc.bin
  radeon/verde_smc.bin
  radeon/VERDE_smc.bin
+ radeon/verde_k_smc.bin
+ radeon/bonaire_k_smc.bin
+ radeon/hawaii_k_smc.bin
+ radeon/oland_k_smc.bin
+ radeon/pitcairn_k_smc.bin
+ radeon/hainan_k_smc.bin
+ radeon/tahiti_k_smc.bin
 uri: http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git
 
 [r128/r128_cce.bin_base]
-- 
2.10.2



signature.asc
Description: OpenPGP digital signature