Bug#842891: libimage-info-perl: XXE in SVG files

[Salvatore Bonaccorso]

Source: libimage-info-perl
Version: 1.28-1
Severity: grave
Tags: security upstream fixed-upstream
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=118099

Hi

[N.B.: Agreed, the severity might be set too high, but I think it
would be good to have the fix for stretch, thus the RC severity].

It was reported that Image::Info is suspectible to  XXE in SVG files.
Cf.

https://rt.cpan.org/Public/Bug/Display.html?id=118099
https://bugzilla.redhat.com/show_bug.cgi?id=1379556

It was already fixed in 1.39 upstream.

Regards,
Salvatore

Bug#842798: compiz: Include Compiz on Debian repositories

[Adam Borowski]

On Tue, Nov 01, 2016 at 12:39:39PM +0100, jEsuSdA wrote:
> Package: compiz
> Version: 0.8.12.3-0~jessie1
> Severity: wishlist
> 
> Please, reconsider to re-include Compiz on the official repositories.
> 
> There are a group of mantainers that are achieved to mantain compiz for 
> Debian.
> 
> http://compiz-debian.tuxfamily.org/
> 
> Maybe support them re-including theyr packages into Debian, could be a good 
> way
> to bring this nice compositing manager to all Debian users.
> 
> I've tested it and it works nice on debian Testing.

There is https://bugs.debian.org/722451 but that 1. talks about compiz 0.9
which is a complete rewrite, 2. is stalled since forever.

I'd recommend you or that new team to follow the usual procedure for
introducing new (or returning) packages.  If you need help, the
debian-ment...@lists.debian.org list can render assistance.  Once the
packages are ready for upload, you can ask for sponsored uploads by filing
RFS bugs -- a process that until recently took months or longer but has
greatly improved since.

Because of stretch freeze coming very soon, I'd recommend hurry.

It is great to hear the classic branch of compiz having a new upstream, and
they appear to be active, too!  Because of divergences with Ubuntu's compiz,
I'd suggest renaming it to reduce confusion, just like Gnome2 became Mate as
its regular upstream became, uhm, peculiar.  I see the git repository is
already named "compiz-reloaded".


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#842890: mark ppp-dev Multi-Arch: foreign

[Helmut Grohne]

Package: ppp-dev
Version: 2.4.7-1+3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:fso-gsmd src:isdnutils src:network-manager 
src:network-manager-pptp src:pptpd

The affected packages cannot satisfy their cross build dependencies,
because their dependency on ppp-dev is unsatisfiable. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign. In this case, such a marking is
correct, because ppp-dev does not have any maintainer scripts or
dependencies. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ppp-2.4.7/debian/changelog ppp-2.4.7/debian/changelog
--- ppp-2.4.7/debian/changelog  2016-08-29 01:15:43.0 +0200
+++ ppp-2.4.7/debian/changelog  2016-11-02 06:47:45.0 +0100
@@ -1,3 +1,10 @@
+ppp (2.4.7-1+3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark ppp-dev Multi-Arch: foreign (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 02 Nov 2016 06:47:34 +0100
+
 ppp (2.4.7-1+3) unstable; urgency=medium
 
   * PPPoE: permit setting an arbitrary Host-Uniq field value:
diff --minimal -Nru ppp-2.4.7/debian/control ppp-2.4.7/debian/control
--- ppp-2.4.7/debian/control2016-06-29 22:47:43.0 +0200
+++ ppp-2.4.7/debian/control2016-11-02 06:47:32.0 +0100
@@ -41,6 +41,7 @@
 Package: ppp-dev
 Section: devel
 Architecture: all
+Multi-Arch: foreign
 Priority: extra
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: debhelper

Bug#842889: ITP: read-pkg -- Read a package.json file

[Sruthi Chandran]

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

* Package name: node-read-pkg
  Version : 2.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/read-pkg#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Read a package.json file

Bug#842888: libkate FTCBFS: build depends on host architecture python interpreter

[Helmut Grohne]

Source: libkate
Version: 0.4.1-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libkate fails to cross build from source, because it requests python for
the host architecture, but python is neither installable nor executable
there. Annotating the dependencies to request the interpreter for the
build architecture is sufficient to make a cross build succeed. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru libkate-0.4.1/debian/changelog 
libkate-0.4.1/debian/changelog
--- libkate-0.4.1/debian/changelog  2016-02-17 15:34:40.0 +0100
+++ libkate-0.4.1/debian/changelog  2016-11-02 06:32:54.0 +0100
@@ -1,3 +1,10 @@
+libkate (0.4.1-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: multiarchify python Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 02 Nov 2016 06:32:35 +0100
+
 libkate (0.4.1-7) unstable; urgency=medium
 
   * Fix wrong name used in autopkgtest test script.
diff --minimal -Nru libkate-0.4.1/debian/control libkate-0.4.1/debian/control
--- libkate-0.4.1/debian/control2016-02-10 08:17:56.0 +0100
+++ libkate-0.4.1/debian/control2016-11-02 06:32:33.0 +0100
@@ -5,7 +5,7 @@
  Petter Reinholdtsen 
  , Martin Steghöfer 
  , Ralph Giles 
-Build-Depends: dh-exec (>=0.3), debhelper (>= 9), dh-autoreconf, 
autotools-dev, python-all-dev, dh-python, liboggz-dev, pkg-config, libpng-dev, 
doxygen
+Build-Depends: dh-exec (>=0.3), debhelper (>= 9), dh-autoreconf, 
autotools-dev, python-all-dev:any, libpython-all-dev, dh-python, liboggz-dev, 
pkg-config, libpng-dev, doxygen
 Standards-Version: 3.9.6
 Section: libs
 Homepage: http://code.google.com/p/libkate/

Bug#842887: dh-make-perl: remove headers from Contents test files

[Paul Wise]

Source: dh-make-perl
Severity: wishlist
Usertags: contents-headers

Please remove the headers from the Contents test files, as Debian has
done and Ubuntu will be doing soon:

https://sources.debian.net/src/dh-make-perl/unstable/t/contents/
https://bugs.debian.org/841997
https://bugs.launchpad.net/bugs/1638219

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#842786: numix-icon-theme: FTBFS (dpkg-source can't extract orig tarball)

[Ben Hutchings]

On Wed, 2016-11-02 at 00:39 +0100, Santiago Vila wrote:
> On Tue, Nov 01, 2016 at 03:11:20PM -0600, Ben Hutchings wrote:
> 
> > 'Cloned chroot' doesn't imply that at all.  And most buildds are
> > running the kernel from stable, which doesn't include overlayfs.
> 
> 
> Well, if you are sure that this will not happen in the official
> buildds, then repacking is not necessary at all.
> 
> Would be ok for you if we just reassign this to "linux"?

You can if you want, but all I will do then is tag it upstream and
downgrade to wishlist.  I believe the upstream developers of overlayfs
are well aware of limitations like this.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special
case.



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

Bug#632585: Debian bug#632585 bsdiff: make it a little less memory hungry

[Jari Aalto]

tags 632585 + fixed pending
thanks

On 2016-10-31 23:28, Sebastian Andrzej Siewior wrote:
| 
| I re-opened #632585 and added three patches to it. I seems I forgot #1
| back then. I applied everything and then tested it via:
| 
| cat libreoffice_4.3.2.orig-external.tar.xz\
|   libreoffice_4.3.3.orig-external.tar.xz  \
|   libreoffice-l10n-id_5.2.3~rc1-4_all.deb \
|   libreoffice_5.2.2~rc2.orig-tarballs.tar.xz  \
|   libreoffice_5.2.3~rc1.orig-tarballs.tar.xz > file-old.bin
| 
| cat libreoffice_4.3.3.orig-external.tar.xz\
|   libreoffice-wiki-publisher_1.2.0+LibO5.2.3~rc1-4~bpo8+1_all.deb \
|   libreoffice_4.3.2.orig-external.tar.xz \
|   libreoffice_5.2.3~rc1.orig-tarballs.tar.xz \
|   libreoffice_5.2.2~rc2.orig-tarballs.tar.xz > file-new.bin
| 
| ./bsdiff file-old.bin file-new.bin old-to-new.bsdiff
| 
| It took around 40min and completed on a box with 16GiB memory (and a
| little stuff in the background). The result was 1.5M MiB file. bspatch
| produced the correct file.
| 
| To compare:
| - xdelta3 run for a minute or so and then aborted with an xz error
| - xdelta run less than a minute and produced also a 1.5 MiB file.

Now included in Debian 

https://anonscm.debian.org/cgit/collab-maint/bsdiff.git/tree/debian/patches
https://anonscm.debian.org/cgit/collab-maint/bsdiff.git/commit/?id=826894b2508352fdc0bbd717ed0bcb8a10c09f6c

Thanks Sebastian for all your work,
Jari

Bug#842838: Reassigning #842838

[殷啟聰]

Control: reassign -1 gradle-debian-helper 1.4
Control: tags -1 + fixed

I believe this bug is fixed by
.

Bug#842886: sbd: FTBFS with ld --as-needed

[Logan Rosen]

Package: sbd
Version: 1.2.0-109-gc511b06-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

sbd currently fails to build with ld --as-needed, which needs the linked 
libraries
to come after the objects that need them. LDFLAGS should only be used for 
linker options.

See 
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries 
for more
information.

In Ubuntu, the attached patch was applied to achieve the following:

  * Merge from Debian unstable. Remaining changes:
- debian/patches/ld-as-needed.patch: Use LDADD instead of LDFLAGS to fix
  FTBFS with ld --as-needed.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru sbd-1.2.0-109-gc511b06/debian/patches/ld-as-needed.patch sbd-1.2.0-109-gc511b06/debian/patches/ld-as-needed.patch
--- sbd-1.2.0-109-gc511b06/debian/patches/ld-as-needed.patch	1969-12-31 19:00:00.0 -0500
+++ sbd-1.2.0-109-gc511b06/debian/patches/ld-as-needed.patch	2016-05-22 17:40:07.0 -0400
@@ -0,0 +1,15 @@
+Description: use LDADD instead of LDFLAGS to fix FTBFS with ld --as-needed
+Author: Logan Rosen 
+Bug: https://github.com/ClusterLabs/sbd/pull/9
+Last-Update: 2016-05-22
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -11,5 +11,5 @@
+ sbd_SOURCES += sbd-md.c
+ endif
+ 
+-sbd_LDFLAGS = $(glib_LIBS) $(libcoroipcc_LIBS)
++sbd_LDADD = $(glib_LIBS) $(libcoroipcc_LIBS)
+ 
diff -Nru sbd-1.2.0-109-gc511b06/debian/patches/series sbd-1.2.0-109-gc511b06/debian/patches/series
--- sbd-1.2.0-109-gc511b06/debian/patches/series	2016-07-04 01:46:25.0 -0400
+++ sbd-1.2.0-109-gc511b06/debian/patches/series	2016-11-02 00:12:38.0 -0400
@@ -1,3 +1,4 @@
 sbd.service.in-kill-path
 sbd-service_sysconfig-vs-default.patch
 cl_log-format-security.patch
+ld-as-needed.patch

Bug#842885: mk-origtargz: shouldn't fail when file downloaded is uncompressed tar archive

[Sean Whitton]

Package: devscripts
Version: 2.16.8
Severity: normal
File: /usr/bin/mk-origtargz

The watch file of the seq-el source package downloads an uncompressed
tar archive.  uscan then invokes mk-origtargz to "repack" the file with
xz compression.  However, this fails because $tar_regex in mk-origtargz
doesn't match uncompressed tar archives.  Is there any reason that
\.tar$ couldn't be added to the regex?

Thanks.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBCHANGE_FORCE_SAVE_ON_RELEASE=no
DEBRELEASE_UPLOADER=dput
DEBSIGN_KEYID=0x0F56D0553B6D411B
DEB_SIGN_KEYID=0x0F56D0553B6D411B
DEBSIGN_PROGRAM=gpg
DSCVERIFY_KEYRINGS=~/.gnupg/pubring.kbx
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc"

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.10
ii  libc62.24-5
ii  perl 5.24.1~rc3-3
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.3.1
ii  at  3.1.20-1
ii  curl7.50.1-1
ii  dctrl-tools 2.24-2
ii  debian-keyring  2016.09.04
ii  dput0.10.3
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-2
ii  file1:5.28-4
ii  gnupg   2.1.15-4
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.24-1
ii  lintian 2.5.49
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.29
ii  python3-magic   1:5.28-4
ii  sensible-utils  0.0.9
ii  strace  4.13-0.1
ii  unzip   6.0-20
ii  wdiff   1.2.2-1+b1
ii  wget1.18-4
ii  xz-utils5.2.2-1.2

Versions of packages devscripts suggests:
ii  adequate 0.15.1
ii  autopkgtest  4.1
ii  bls-standalone   0.20151231
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-3
ii  build-essential  12.2
ii  check-all-the-things 2016.09.03
pn  cvs-buildpackage 
pn  devscripts-el
ii  diffoscope   61
pn  disorderfs   
ii  dose-extra   5.0.1-2
ii  duck 0.10
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-2
ii  gpgv 2.1.15-4
ii  how-can-i-help   14
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mozilla-devscripts   0.47
ii  mutt 1.7.1-2
ii  openssh-client [ssh-client]  1:7.3p1-1
ii  piuparts 0.72
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.6
ii  w3m  0.5.3-31

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#842806: docker.io: Can't connect to the daemon

[Tianon Gravi]

On 1 November 2016 at 05:35, Kurt Roeckx  wrote:
> The file /var/run/docker.sock seems to exist, is created when it starts,
> but it really seems to be listening to an other socket.
>
> The process that's running shows:
> containerd -l /var/run/docker/libcontainerd/docker-containerd.sock --runtime 
> runc --start-timeout 2m

Are you using systemd, or sysvinit?  Anything interesting in the
daemon logs? ("journalctl -u docker.service" for systemd,
"/var/log/docker.log" for sysvinit IIRC)

Also, are you in the "docker" group? (or running "docker ..." as root
so that you have appropriate permission to talk to the socket?)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#842786: numix-icon-theme: FTBFS (dpkg-source can't extract orig tarball)

[Jeremy Bicha]

On Tue, Nov 1, 2016 at 5:57 AM, Santiago Vila  wrote:
> The original tarball does not contain any directories:
>
> $ tar tvf numix-icon-theme_0~20160619.217701b.orig.tar.xz | grep ^d
> [ no output at all ]

I think your syntax is wrong because the original tarball definitely
does contain directories: your log snippet itself shows 9 directories!
But why only 9? there's a lot more directories than that. A silly
question, but have you tried the build a second time, in case perhaps
the tarball you downloaded got corrupted or something?

I don't particularly like the code in debian/rules that's used the
create the original tarball; instead I'd prefer if uscan could gain
native git snapshot support [1] or if the numix-icon-theme developers
would actually tag releases [2]. As I commented in debian/rules, the
code is inspired by what I found other packages doing. I will replace
mine with simpler code if someone wants to submit it.

[1] https://bugs.debian.org/811565
[2] https://github.com/numixproject/numix-icon-theme/issues/1089

Thanks,
Jeremy

Bug#842877: apt: does not set HOME before invoking gnupg

[brian m. carlson]

severity 842877 minor
retitle 842877 apt: should sanitize environment more thoroughly
kthxbye

On Wed, Nov 02, 2016 at 02:38:20AM +0100, David Kalnischkies wrote:
> On Tue, Nov 01, 2016 at 11:49:39PM +, brian m. carlson wrote:
> > 1. Add a new mirror to /etc/apt/sources.list.
> 
> Can you go into more detail what you do in this step please?
> Are you installing -keyring packages perhaps?

No, simply adding a new Debian mirror is sufficient.  In fact, that's
not even required.  All that's required is to make apt validate a GnuPG
signature, so this will happen at least once a day anyway.

It doesn't occur if apt doesn't validate a signature.

> > 2. Set "extra-socket ~/.gnupg/S.gpg-agent-extra" in your user's
> >~/.gnupg/gpg-agent.conf
> > 3. As an unprivileged user in the sudo group, run "sudo -E apt-get update".
> > 4. Notice that there is now a root-owned gpg-agent running which has
> >inherited your user's homedir and configuration settings.
> > 5. Notice that your extra socket has been overwritten by root's gpg-agent.
> 
> apt-key as called by apt doesn't use gnupg. The functionality apt is
> using from apt-key is gpgv only and that isn't spawning agents or
> whatever as there is no secret key material to protect.
> 
> So, figuring out what is calling gpg would be good – or what is calling
> apt-key [which likely shouldn't be called it].

Ah, I think the problem could be that you end up invoking $SHELL (for
me, zsh) somewhere (directly or indirectly), and therefore triggering my
shell to spawn a new gpg-agent, since it reads from my home directory.

I can work around this issue, but I would say you probably don't want
either my $HOME or my $SHELL for subprocesses.  In fact, you probably
want to sanitize the environment for subprocesses more thoroughly
altogether to avoid this problem.  I know apt has broken in the past
because it inherited a root-only $TMPDIR.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing

[Russ Allbery]

Sam Hartman  writes:

> Shibboleth comprises opensaml, xmltooling, heavily depends on
> xml-security-c and shibboleth-sp2.

> Ferenc Wágner (copied) has been handling the Shibboleth packaging and
> has an understanding of where the upstream efforts are.  There's been
> discussion on pkg-shibboleth-...@lists.alioth.debian.org.

Shibboleth upstream has said that they believe the porting effort to be
substantial, since Shibboleth (specifically the lower-level libraries)
heavily use OpenSSL key management and manipulation APIs that are very
affected by the API change, and because (as security software) the
consequences of making a small error in the API change can be very high.

Upstream is working on the changes and on comprehensive tests to ensure
that the port was done correctly, but their timeline doesn't line up well
with our release freeze.

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

Bug#837359: ocaml: FTBFS on -fPIE binNMU on armhf - test failure

[Ximin Luo]

Ximin Luo:
> Ximin Luo:
>>
>> It's possible OCaml itself is to blame:
>>
>> asmcomp/arm/emit.mlp:
>> if nh = 0l then begin
>>   `  movw{emit_reg dst}, #{emit_int32 nl}\n`; 1
>> end else if Int32.logand nl 0xffl = nl then begin
>>   `  movs{emit_reg dst}, #{emit_int32 nl}\n`;
>>   `  movt{emit_reg dst}, #{emit_int32 nh}\n`; 2
>> end else begin
>>   `  movw{emit_reg dst}, #{emit_int32 nl}\n`;
>>   `  movt{emit_reg dst}, #{emit_int32 nh}\n`; 2
>> end
>>

Sorry, wrong snippet. The above code is not relevant for what we're observing 
below. The correct snippet is this:

let emit_load_symbol_addr dst s =
  if !Clflags.pic_code then begin
[..]
  end else if !arch > ARMv6 && not !Clflags.dlcode && !fastcode_flag then begin
`   movw{emit_reg dst}, #:lower16:{emit_symbol s}\n`;
`   movt{emit_reg dst}, #:upper16:{emit_symbol s}\n`;
2

Note that !arch in ocaml means "get the current value of the mutable reference 
'arch'".

It looks like they already wrote the working code, it's just not being emitted 
here. So I just need to figure out how to make Cflags.pic_code true, which 
shouldn't be too hard. I will try this tomorrow when I'm less tired.

>> Judging by http://lists.denx.de/pipermail/u-boot/2013-September/163154.html 
>> this might be invalid for ARM and PIC.
>>
>> (sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ rm 
>> quicksort2.s quicksort2.o
>>
>> (sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ make 
>> CASES=quicksort2  MLCASES= MLCASES_FLAMBDA=
>> make[1]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>> make[2]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>> make[2]: Nothing to be done for 'arch'.
>> make[2]: 'codegen' is up to date.
>> make[2]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>> make[2]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>>  ... testing 'quicksort2':make[3]: Entering directory 
>> '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>> /usr/bin/ld: quicksort2.o: relocation R_ARM_THM_MOVW_ABS_NC against `cmp' 
>> can not be used when making a shared object; recompile with -fPIC
>> quicksort2.o: error adding symbols: Bad value
>> collect2: error: ld returned 1 exit status
>>  => failed
>> make[3]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>> make[2]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>> make[1]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>>
>> (sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ grep -n 
>> mov[tw] quicksort2.s
>> 138:movwr3, #:lower16:cmp
>> 139:movtr3, #:upper16:cmp
>>
>> Could someone else more familiar with ARM and/or OCaml comment please?
>>
> 
> And in fact manually editing quicksort2.s to change the movt/w expressions to 
> "r3, 0", commenting out the "codegen" part of the .cmm.o rule in 
> Makefile.common, then running the above test command again, will make it 
> pass. So the emitted instructions are likely what's at fault, but I don't 
> know ARM well enough to suggest how to fix it properly.
> 
> X
> 

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

Bug#837359: ocaml: FTBFS on -fPIE binNMU on armhf - test failure

[Ximin Luo]

Ximin Luo:
> Adrian Bunk:
>>  ... testing 'quicksort2':/usr/bin/ld: quicksort2.o: relocation 
>> R_ARM_THM_MOVW_ABS_NC against `cmp' can not be used when making a shared 
>> object; recompile with -fPIC
>> quicksort2.o: error adding symbols: Bad value
>> collect2: error: ld returned 1 exit status
>>  => failed
>>  ... testing 'soli':/usr/bin/ld: soli.o: relocation R_ARM_THM_MOVW_ABS_NC 
>> against `a local symbol' can not be used when making a shared object; 
>> recompile with -fPIC
>> soli.o: error adding symbols: Bad value
>> collect2: error: ld returned 1 exit status
>>  => failed
>>  ... testing 'arith':/usr/bin/ld: arith.o: relocation R_ARM_THM_MOVW_ABS_NC 
>> against `D' can not be used when making a shared object; recompile with -fPIC
>> arith.o: error adding symbols: Bad value
>> collect2: error: ld returned 1 exit status
>>  => failed
>>  ... testing 'tagged-integr':/usr/bin/ld: tagged-integr.o: relocation 
>> R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a 
>> shared object; recompile with -fPIC
>> tagged-integr.o: error adding symbols: Bad value
>> collect2: error: ld returned 1 exit status
>>  => failed
>>
>> Several other testcases are building fine.
>>
>> The odd thing is that these worked on armel and arm64 but failed on armhf.
>>
>> Note that the "recompile with -fPIC" error message can be misleading.
>> It is also given when building binaries where only PIE is required
>> (which is the default in the gcc used).
>>
> 
> It's possible OCaml itself is to blame:
> 
> asmcomp/arm/emit.mlp:
> if nh = 0l then begin
>   `   movw{emit_reg dst}, #{emit_int32 nl}\n`; 1
> end else if Int32.logand nl 0xffl = nl then begin
>   `   movs{emit_reg dst}, #{emit_int32 nl}\n`;
>   `   movt{emit_reg dst}, #{emit_int32 nh}\n`; 2
> end else begin
>   `   movw{emit_reg dst}, #{emit_int32 nl}\n`;
>   `   movt{emit_reg dst}, #{emit_int32 nh}\n`; 2
> end
> 
> Judging by http://lists.denx.de/pipermail/u-boot/2013-September/163154.html 
> this might be invalid for ARM and PIC.
> 
> (sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ rm 
> quicksort2.s quicksort2.o
> 
> (sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ make 
> CASES=quicksort2  MLCASES= MLCASES_FLAMBDA=
> make[1]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> make[2]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> make[2]: Nothing to be done for 'arch'.
> make[2]: 'codegen' is up to date.
> make[2]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> make[2]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
>  ... testing 'quicksort2':make[3]: Entering directory 
> '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> /usr/bin/ld: quicksort2.o: relocation R_ARM_THM_MOVW_ABS_NC against `cmp' can 
> not be used when making a shared object; recompile with -fPIC
> quicksort2.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>  => failed
> make[3]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> make[2]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> make[1]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
> 
> (sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ grep -n 
> mov[tw] quicksort2.s
> 138:movwr3, #:lower16:cmp
> 139:movtr3, #:upper16:cmp
> 
> Could someone else more familiar with ARM and/or OCaml comment please?
> 

And in fact manually editing quicksort2.s to change the movt/w expressions to 
"r3, 0", commenting out the "codegen" part of the .cmm.o rule in 
Makefile.common, then running the above test command again, will make it pass. 
So the emitted instructions are likely what's at fault, but I don't know ARM 
well enough to suggest how to fix it properly.

X

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

Bug#840306: /usr/bin/nvim: SIGTSTP leaves terminal in a strange state

[Jason Rhinelander]

Upstream fix: 
https://github.com/neovim/neovim/commit/36c0ec6dd49c8c1a57eaa0b9f9d3c44792582f37


Please consider this a friendly request for a 0.1.6-2 package with this 
(simple) patch included: being able to Ctrl-Z nvim and use the shell 
normally for a few commands is something I rely on quite a bit.



Jason Rhinelander

Bug#837359: ocaml: FTBFS on -fPIE binNMU on armhf - test failure

[Ximin Luo]

Adrian Bunk:
>  ... testing 'quicksort2':/usr/bin/ld: quicksort2.o: relocation 
> R_ARM_THM_MOVW_ABS_NC against `cmp' can not be used when making a shared 
> object; recompile with -fPIC
> quicksort2.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>  => failed
>  ... testing 'soli':/usr/bin/ld: soli.o: relocation R_ARM_THM_MOVW_ABS_NC 
> against `a local symbol' can not be used when making a shared object; 
> recompile with -fPIC
> soli.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>  => failed
>  ... testing 'arith':/usr/bin/ld: arith.o: relocation R_ARM_THM_MOVW_ABS_NC 
> against `D' can not be used when making a shared object; recompile with -fPIC
> arith.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>  => failed
>  ... testing 'tagged-integr':/usr/bin/ld: tagged-integr.o: relocation 
> R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a 
> shared object; recompile with -fPIC
> tagged-integr.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
>  => failed
> 
> Several other testcases are building fine.
> 
> The odd thing is that these worked on armel and arm64 but failed on armhf.
> 
> Note that the "recompile with -fPIC" error message can be misleading.
> It is also given when building binaries where only PIE is required
> (which is the default in the gcc used).
> 

It's possible OCaml itself is to blame:

asmcomp/arm/emit.mlp:
if nh = 0l then begin
  ` movw{emit_reg dst}, #{emit_int32 nl}\n`; 1
end else if Int32.logand nl 0xffl = nl then begin
  ` movs{emit_reg dst}, #{emit_int32 nl}\n`;
  ` movt{emit_reg dst}, #{emit_int32 nh}\n`; 2
end else begin
  ` movw{emit_reg dst}, #{emit_int32 nl}\n`;
  ` movt{emit_reg dst}, #{emit_int32 nh}\n`; 2
end

Judging by http://lists.denx.de/pipermail/u-boot/2013-September/163154.html 
this might be invalid for ARM and PIC.

(sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ rm 
quicksort2.s quicksort2.o

(sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ make 
CASES=quicksort2  MLCASES= MLCASES_FLAMBDA=
make[1]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
make[2]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
make[2]: Nothing to be done for 'arch'.
make[2]: 'codegen' is up to date.
make[2]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
make[2]: Entering directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
 ... testing 'quicksort2':make[3]: Entering directory 
'/home/infinity0/ocaml/testsuite/tests/asmcomp'
/usr/bin/ld: quicksort2.o: relocation R_ARM_THM_MOVW_ABS_NC against `cmp' can 
not be used when making a shared object; recompile with -fPIC
quicksort2.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
 => failed
make[3]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
make[2]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'
make[1]: Leaving directory '/home/infinity0/ocaml/testsuite/tests/asmcomp'

(sid_armhf-dchroot)infinity0@harris:~/ocaml/testsuite/tests/asmcomp$ grep -n 
mov[tw] quicksort2.s
138:movwr3, #:lower16:cmp
139:movtr3, #:upper16:cmp

Could someone else more familiar with ARM and/or OCaml comment please?

X

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

Bug#837928: Bug#837925: usrmerge: fails to merge with molly-guard installed

[Jonas Smedegaard]

[dropping Marco from cc]

Quoting Jonas Smedegaard (2016-11-02 02:19:42)
> I don't know how it is wrong, just experienced that it failed, and 
> when I looked mollyguard was not registered with dpkg-divert.  I have 
> had molly-guard installed for quite some time, so perhaps that newer 
> behaviour was not applied to existing installs?

Ah - seems this same issue emerges when upgrading a system installed 
from scratch few days ago:

Preparing to unpack .../0-systemd-sysv_231-9_armhf.deb ...
Unpacking systemd-sysv (231-9) over (231-4) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-CgGd9t/0-systemd-sysv_231-9_armhf.deb (--unpack):
 trying to overwrite '/sbin/halt', which is also in package molly-guard 0.6.4


I am busy getting that system to production use (yes, stretch is not yet 
stable, but more stable than stable on the ARM device I use), but if you 
have suggestions for closer inspections that might help shed some light 
on this issue, please shoot - fast.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#842884: RFS: scram/0.11.4-1 [ITP]

[Olzhas Rakhimov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: scram
  Version : 0.11.4-1
  Upstream Author : Olzhas Rakhimov 
* URL : http://scram-pra.org/
* License : GPLv3
  Section : science

It builds those binary packages:

  scram - Probabilistic Risk Analysis Tool

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/scram/scram_0.11.4-1.dsc


Regards,
 Olzhas Rakhimov

Bug#783377: Packaging new version of ZODB (Zope Object Database)

[Arnaud Fontaine]

Hi,

> I write  to debian-python, because  some of the involved  packages are
> not specific to  Zope. Actually, I even think that  ZODB itself is not
> specific to Zope, but well,  changing section of existing packages can
> be another topic.

This has  already been discussed  but all  the packages in  pkg-zope SVN
repository will have to be  moved to python-{modules, apps} repositories
(because there  is almost no activity  on pkg-zope and most  modules are
used independently  of Zope anyway)  and we should use  debian-python ML
for the  same reason,  so yes,  please use  debian-python ML  and commit
everything to python-{modules, apps} repositories.

Also, let  me know  when you  want to  upload as  I can  sponsor without
problem.

Cheers,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#842883: RFS: scram/0.11.4-1 [ITP]

[Olzhas Rakhimov]

Package: scram
Severity: wishlist

Dear mentors,

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

* Package name: scram
  Version : 0.11.4-1
  Upstream Author : Olzhas Rakhimov 
* URL : http://scram-pra.org/
* License : GPLv3
  Section : science

It builds those binary packages:

  scram - Probabilistic Risk Analysis Tool

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/scram/scram_0.11.4-1.dsc


Regards,
 Olzhas Rakhimov

Bug#842877: apt: does not set HOME before invoking gnupg

[David Kalnischkies]

Hi

On Tue, Nov 01, 2016 at 11:49:39PM +, brian m. carlson wrote:
> 1. Add a new mirror to /etc/apt/sources.list.

Can you go into more detail what you do in this step please?
Are you installing -keyring packages perhaps?


> 2. Set "extra-socket ~/.gnupg/S.gpg-agent-extra" in your user's
>~/.gnupg/gpg-agent.conf
> 3. As an unprivileged user in the sudo group, run "sudo -E apt-get update".
> 4. Notice that there is now a root-owned gpg-agent running which has
>inherited your user's homedir and configuration settings.
> 5. Notice that your extra socket has been overwritten by root's gpg-agent.

apt-key as called by apt doesn't use gnupg. The functionality apt is
using from apt-key is gpgv only and that isn't spawning agents or
whatever as there is no secret key material to protect.

So, figuring out what is calling gpg would be good – or what is calling
apt-key [which likely shouldn't be called it].


> apt needs to set HOME before invoking gnupg so that the spawned
> gpg-agent does not inherit the user's (or root's) homedir.  The

mhhh. Even if apt-key is calling gpg, it invokes it with its own fresh
GPGHOMEDIR it has created in TMPDIR. It shouldn't be even near HOME,
neither of USER nor of root.



I haven't a sudo setup here at the moment I could test this with.
I guess I will try that later "today" (after having slept a bit), but
perhaps you can shine some additional light on this while I cuddle with
my pillow with those questions already…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#842817: yorick-hdf5: FTBFS against HDF5 v1.10

[Gilles Filippini]

Hi Thibaut,

Thibaut Paumard a écrit le 01/11/2016 à 22:51 :
> Thanks Gilles.
> 
> This is due to hid_t changing from 32bit to 64bit and mapping that to
> the correct integer type in Yorick.
> 
> I managed a quick fix, need a little more time to upload it.

Thanks for the follow-up. I'm curious how you fix it, because as I
understand it, yorick doesn't support 64 bits integers o_O

Regards,

_g.

> 
> Regards, Thibaut.
> 
> Le 01/11/2016 à 14:16, Gilles Filippini a écrit :
>> Source: yorick-hdf5
>> Version: 0.8.0-5
>> Severity: important
>>
>> Hi,
>>
>> yorick-hdf5 FTBFS againt HDF5 v1.10 currently in experimental:
>>
>>dh_auto_test
>> make -j1 check
>> make[1]: Entering directory '/<>'
>> /usr/lib/yorick/bin/yorick -batch check.i
>>  Creating data.h5 with data
>> ERROR (h5write) Unable to create group
>>   LINE: 785  FILE: /<>/hdf5.i
>> yorick: quitting on error in batch mode
>> /usr/lib/yorick/Makepkg:159: recipe for target 'check-dll' failed
>> make[1]: *** [check-dll] Error 1
>> make[1]: Leaving directory '/<>'
>> dh_auto_test: make -j1 check returned exit code 2
>> debian/rules:9: recipe for target 'build' failed
>> make: *** [build] Error 2
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>>
>> Full build log attached.
>>
>> Thanks,
>>
>> _g.
>>
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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)
>>
>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Bug#842882: jp2a: Version 1.0.7 improper to be released

[Joao Eriberto Mota Filho]

Package: jp2a
Version: 1.0.7-1
Severity: important
Tags: upstream

The upstream declared that 1.0.7 version was a mistake. More details here:

https://github.com/cslarsen/jp2a/issues/6#issuecomment-257672782

This version is in experimental and cannot be send to unstable.

Eriberto

Bug#837928: Bug#837925: usrmerge: fails to merge with molly-guard installed

[Jonas Smedegaard]

Quoting Francois Marier (2016-11-01 22:14:43)
> On 2016-11-01 at 18:48:51, Jonas Smedegaard wrote:
> > I don't know how to be more exact than how I wrote it initially for 
> > this bugreport.
> > 
> > Could you perhaps elaborate on what details you are missing?
> 
> You wrote this:
> 
> "molly-guard adds wrappers for commands like pm-hibernate and 
> poweroff.
> 
> The wrappers are added not using dpkg-divert but as symlinks in /sbin, 
> where the wrapped commands reside in /usr/sbin."
> 
> But the wrappers _are_ added using dpkg-divert:
> 
> https://anonscm.debian.org/cgit/collab-maint/molly-guard.git/tree/debian/molly-guard.preinst?id=1a3675db6ae1015c4d6e8367c7132c87fb9f3b31#n25
> 
> which looks like this on my machine:
> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 28 Aug 15 22:16 /sbin/reboot -> 
> /lib/molly-guard/molly-guard
> 
> So what's wrong with this use of dpkg-divert?

Thanks for elaborating.

I don't know how it is wrong, just experienced that it failed, and when 
I looked mollyguard was not registered with dpkg-divert.  I have had 
molly-guard installed for quite some time, so perhaps that newer 
behaviour was not applied to existing installs?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#842881: libmpich12: extraneous - and possibly wrong - symbolic link: /usr/lib/libmpich.so.12 -> libmpi.so

[Gilles Filippini]

Package: libmpich12
Version: 3.2-7
Severity: serious
Justification: make other packages FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I've just experienced a weird FTBFS on hdf5 on my box, caused by an
extraneous symlink:
/usr/lib/libmpich.so.12 -> libmpi.so

Steps to reproduce:
1- Start from an unstable sbuild chroot
2- apt-get install libmpich-dev
3- apt-get install libopenmpi-dev

Result:
/usr/lib/libmpich.so.12 -> libmpi.so
/usr/lib/libmpi.so -> /etc/alternatives/libmpi.so
/etc/alternatives/libmpi.so -> /usr/lib/openmpi/lib/libmpi.so
/usr/lib/openmpi/lib/libmpi.so -> libmpi.so.20.0.1

In other words, /usr/lib/libmpich.so.12 is a symlink to
/usr/lib/openmpi/lib/libmpi.so.20.0.1 from libopenmpi2.

This link is created by ldconfig if and only if /usr/lib/libmpi.so
exists:
1- Start again from an unstable sbuild chroot
2- apt-get install libmpich12
   => no /usr/lib/libmpich.so.12 symlink
3- apt-get install libmpich-dev
   => still no /usr/lib/libmpich.so.12 symlink
4- ldconfig -v | grep changed
libmpich.so.12 -> libmpi.so (changed)
libmpichcxx.so.12 -> libmpicxx.so (changed)
libmpichfort.so.12 -> libmpif90.so (changed)

I have no idea how to solve this problem :/

Thanks,

_g.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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)

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYGT3hAAoJEO/obGx//s+D5zQH/R9TUA/zyUMgmDugJr5sI36h
C4DMVbFuv4a6yOb9wR4x5w6JEpmOUrK9++bUWRcwUCQwRgZqjBx1mQL/7hzpHNcd
xb1rRl3et4WBxrPoHzZKqXlN6Hdg+NBGNG+bTpFN/D4vJV4wOJyoX94USp//UcnP
6pUO/GoRLR71aKbs21sf3VrENPPdyOBWLSGljPaQZsU8Uj3GozVX6HLSokz1rFU/
7PRY+I6tOpv53IhpbBLbn+1p/rSnpXYIgkZIHgnPiGxGU0qUjimH2SEwOpVO404g
tTIfosLClvRlNTo66JZH1KRjHdxBI7NYvvVIufKpnjh9PN7y8aBgqq3ER9n/hIQ=
=wGnc
-END PGP SIGNATURE-

Bug#842880: emacs25: Does not enable dynamic modules

[Michael Myers]

Source: emacs25
Severity: normal

Dear Maintainer,

Please consider building with the --with-modules flag to enable the dynamic 
module
feature added in 25.1.



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

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

Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit

[Walter Landry]

Rock Storm  wrote:
> On Mon, 2016-10-31 at 14:02 -0700, Walter Landry wrote:
>> FYI, I created a package for this for my own use.
> 
> That's awesome! Is it uploaded somewhere? Could you share it with me? I
> would love to take a look at it.

I can share it.  Give me a day or so.  The build is ... complicated.

>> It is pretty terrible, but if I find the time, I may be able to make
>> a proper package.  If you already have a proper package, yours is
>> probably better.
> 
> I've been busier than I expected so I haven't done much yet, probably
> merging our efforts is the best option.

Ok.

> Nevertheless, I still have to discuss with legal whether distributing
> this package complies with the DFSG.

For what it is worth, I am a regular on debian-legal.  In this link

  
http://naif.jpl.nasa.gov/pub/naif/toolkit//C/PC_Linux_GCC_64bit/packages/README

I see a disclaimer, but no right to modify.  This link

  https://naif.jpl.nasa.gov/naif/rules.html

allows modification, but not simple redistribution?  To make things
even more muddy, this presentation

  
https://indico.esa.int/indico/event/111/session/27/contribution/130/material/slides/0.pdf

says that it is "free of licensing".

So it is pretty clear that we have to get a clarification on what,
exactly, the license is.  It looks like the person to talk to is the
NAIF manager at JPL.  His contact info is in the 'rules' link.
Clarifying this could, potentially, take a while.

Cheers,
Walter Landry

Bug#783377: Packaging new version of ZODB (Zope Object Database)

[Julien Muchembled]

Le 11/01/16 à 20:10, Julien Muchembled a écrit :
> * python-btrees & python-zodbpickle (done)
> https://github.com/zopefoundation/BTrees
> https://github.com/zopefoundation/zodbpickle
> 
> - new packages
> - Debian Python Modules Team
> 
> [...]
> 
> * python-zeo (not started)
> https://github.com/zopefoundation/ZEO
> 
> [...]
> 
> * zc.customdoctests (done)
> https://github.com/zopefoundation/zc.customdoctests
> 
> - new package
> - Debian Python Modules Team
> 
> I haven't done any ITP yet.

Bug#842870: ITP: zodbpickle -- Fork of pickle module, for ZODB
Bug#842874: ITP: python-btrees -- scalable persistent object containers for 
Python
Bug#842876: ITP: zc.customdoctests -- Use Python doctest with other languages

I'll do ZEO later.

Julien

Bug#842879: get start date from local VPS, not underlying actual computer

[積丹尼 Dan Jacobson]

Package: procps
Version: 2:3.3.12-2
Severity: wishlist

ps should have a way to get the process start time from the local
instance of the VPS, not the entire underlying computer.

$ sleep 4& ps -eo pid,cmd,start_time,bsdstart,start,lstart,stime|grep 
sleep|grep -v grep
15772 sleep 4 Aug25 Aug 25   Aug 25 Thu Aug 25 15:41:46 
2016 Aug25
$ date
Wed Nov  2 08:10:25 CST 2016

Staff says:
Thank you for contacting DreamHost support. I spoke to one of our admins
and it looks as if the 'ps u' command you're using is pulling information
from the vhost of your VPS which is why it's showing an August start time
(Since the machine itself has been up since August). That is not related
to your VPS or dates on your machine really at all as you can see by your
'date' pulling the correct day/time information.

> Isn't that terrible?

So when running that command it is pulling the dates from the host
machine, this isn't anything necessarily wrong with the system and
unfortunately the way the VPS would work. If you wish to view the proper
date for the VPS please use the "date" command. I do apologize for any
inconvenience or confusion that may have been caused. If you have any
other questions or concerns feel free to let us know!

$ ps aux|perl -awnle 'print $F[8]'|sort|uniq -c
 26 Aug09
  4 Aug24
 11 Aug25
  1 START

So that field is nonsense...

Bug#828388: Pending fixes for bugs in the libcrypt-openssl-x509-perl package

[pkg-perl-maintainers]

tag 828388 + pending
thanks

Some bugs in the libcrypt-openssl-x509-perl package are closed in
revision 5fde51ed9473454f3350b3d949600a6675773e8d in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libcrypt-openssl-x509-perl.git/commit/?id=5fde51e

Commit message:

Cherry-pick two commits from upstream Git repo for OpenSSL 1.1.0

compatibility (and 1.0.2 backwards compatibility).

Closes: #828388

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Gedalya]

Package: asterisk
Version: 1:13.11.2~dfsg-1

Hi,

Not sure if this should be filed against asterisk or pjproject.

I've just tried upgrading the pjproject libraries to version 2.5.5~dfsg-1 from 
sid.

With this version, asterisk seems to just exit when trying to dial the inner 
leg of the call. No error shows up, nothing in dmesg either.

-- Executing [gedalya-all@internal:1] 
Set("PJSIP/trunk-vitelity-in-", "CDR(peername)=trunk-vitelity-in") in 
new stack
-- Executing [gedalya-all@internal:2] 
MixMonitor("PJSIP/trunk-vitelity-in-", 
"/var/local/callrec/2016-11/1478045348.0.wav") in new stack
-- Executing [gedalya-all@internal:3] 
Dial("PJSIP/trunk-vitelity-in-", 
"PJSIP/../.././../.,30") in new 
stack
  == Begin MixMonitor Recording PJSIP/trunk-vitelity-in-
asterisk*CLI>
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups

That's all. Nothing in the log either.

After going back to pjproject 2.5.1~dfsg-4 everything works again.

Maybe asterisk just needs to be rebuilt against 2.5.5? I could try this later 
perhaps.

Thanks,

Gedalya

Bug#753143: German quotation marks do not work in Austrian

[Norbert Preining]

Hi Claus,

> Forwarded it to the LaTeX bug tracker. Will see what they answer.

Will be fixed in the next upload I will do these days. Thanks

Norbert

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

Bug#828517: OpenSSL transition severity

[Stefano Rivera]

Hi Kurt (2016.10.27_00:35:51_-0700)
> I just took a pass at it, and I think, did most of the port in an
> afternoon and evening.

Landed upstream, it'll be in the next upstream release.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#842865: atanks: please make the build reproducible

[Jesse Smith]

I will test this patch on a few platforms to make sure it doesn't break
any corner cases and, assuming it works, push it upstream.

Jesse



On 01/11/16 07:29 PM, Reiner Herrmann wrote:
> Source: atanks
> Version: 6.4~dfsg-1
> Severity: wishlist
> Tags: patch upstream
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: fileordering
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi!
> 
> While working on the "reproducible builds" effort [1], we have noticed
> that atanks could not be built reproducibly.
> It links object files in non-deterministic order.
> 
> The attached patch fixes this by sorting the list of source files.
> 
> Regards,
>  Reiner
> 
> [1]: https://wiki.debian.org/ReproducibleBuilds
> 

Bug#842877: apt: does not set HOME before invoking gnupg

[brian m. carlson]

Package: apt
Version: 1.3.1
Severity: important

Steps to reproduce:

1. Add a new mirror to /etc/apt/sources.list.
2. Set "extra-socket ~/.gnupg/S.gpg-agent-extra" in your user's
   ~/.gnupg/gpg-agent.conf
3. As an unprivileged user in the sudo group, run "sudo -E apt-get update".
4. Notice that there is now a root-owned gpg-agent running which has
   inherited your user's homedir and configuration settings.
5. Notice that your extra socket has been overwritten by root's gpg-agent.

In my particular case, this causes my extra socket, which I forward to a
VM for commit-signing purposes, to no longer work.

apt needs to set HOME before invoking gnupg so that the spawned
gpg-agent does not inherit the user's (or root's) homedir.  The
gpg-agent also inherits all of the other gpg-agent.conf settings,
including log-file, pinentry, and other settings.  Behavior which may be
fine and secure for a user may not be fine and secure for root.  apt
also shouldn't be inheriting settings from the homedir of any user
(including root).

I can't think of a way to actually exploit this, since the HOME is
explicitly or implicitly (e.g. via sudo -E) set by root, but it seems
risky.  This is new with the use of GnuPG 2.1 by apt.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.7\.0-rc7-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.7\.0-rc7-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";

Bug#842786: numix-icon-theme: FTBFS (dpkg-source can't extract orig tarball)

[Santiago Vila]

On Tue, Nov 01, 2016 at 03:11:20PM -0600, Ben Hutchings wrote:

> 'Cloned chroot' doesn't imply that at all.  And most buildds are
> running the kernel from stable, which doesn't include overlayfs.

Well, if you are sure that this will not happen in the official
buildds, then repacking is not necessary at all.

Would be ok for you if we just reassign this to "linux"?

Thanks.

Bug#842620: mpv: OSD is gone‽

[James Cowgill]

On 01/11/16 22:52, Salvo Tomaselli wrote:
> Well your workaround doesn't really help. I still need to put the
> mouse on the bottom, while before, to see how long was left, i could
> just move the mouse slightly.

This is the OSC 'deadzone' and is also a configurable setting. Try:
 mpv --script-opts=osc-deadzonesize=0

This is the PR which made all these changes:
https://github.com/mpv-player/mpv/pull/3631

James



signature.asc
Description: OpenPGP digital signature

Bug#842875: lastpass-cli: please make the build reproducible

[Reiner Herrmann]

Source: lastpass-cli
Version: 1.0.0-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Forwarded: https://github.com/lastpass/lastpass-cli/pull/214

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that lastpass-cli could not be built reproducibly.
It links objects in a non-deterministic order.

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

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/02_reproducible_build.patch b/debian/patches/02_reproducible_build.patch
new file mode 100644
index 000..4053270
--- /dev/null
+++ b/debian/patches/02_reproducible_build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/Makefile
 b/Makefile
+@@ -34,7 +34,7 @@
+ doc-html: lpass.1.html
+ doc: doc-man doc-html
+ 
+-lpass: $(patsubst %.c,%.o,$(wildcard *.c))
++lpass: $(patsubst %.c,%.o,$(sort $(wildcard *.c)))
+ %.1: %.1.txt
+ 	a2x --no-xmllint -f manpage $<
+ %.1.html: %.1.txt
diff --git a/debian/patches/series b/debian/patches/series
index 06c3871..9d86d53 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 01_build_manpage
+02_reproducible_build.patch


signature.asc
Description: PGP signature

Bug#842876: ITP: zc.customdoctests -- Use Python doctest with other languages

[Julien Muchembled]

Package: wnpp
Severity: wishlist
Owner: Julien Muchembled 

* Package name: zc.customdoctests
  Version : 1.0.1+1.gc142624-1
  Upstream Author : Zope Foundation and Contributors 
* URL : https://github.com/zopefoundation/zc.customdoctests
* License : Zope-2.1
  Programming Lang: Python
  Description : Use Python doctest with other languages

 doctest (and recently manuel) provide hooks for using custom doctest
 parsers. zc.customdoctests helps to leverage this to support other
 languages, such as JavaScript (with python-spidermonkey):
 .
 js> function double (x) {
 ... return x*2;
 ... }
 js> double(2)
 4
 .
 And with python-manuel, it facilitates doctests that mix multiple languages,
 such as Python, JavaScript, and sh.

This is a required dependency for the new version of ZODB, and I plan to
maintain it as part of the Debian Python Modules Team. See also

 
https://lists.debian.org/msgid-search/8e7791a6-97fd-6a68-8bc2-dee31266c...@jmuchemb.eu

Bug#842819: vim-gtk3: gvim window is miss displayed

[James McCoy]

Control: reassign -1 libgtk-3-0 3.22.2-1
Control: forcemerge 842070 -1 

On Tue, Nov 01, 2016 at 02:32:37PM +0100, gpe92 wrote:
>* What led up to the situation?
>launch gvim
>* What was the outcome of this action?
> 
>The gvim window is miss displayed an unusable (see attached
>screenshot) and there are some erros on the console:
> 
>(gvim:21136): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 
> 'width >= -1' failed
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug

This is a known bug, caused by a change of behavior in gtk3.  There's
ongoing discussion about whether it should be fixed in gtk or Vim.

Reassigning to the Gtk bug (which was already marked as affecting
vim-gtk3, so it should have shown up when you searched for bugs).

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

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[brian m. carlson]

libunbound2 1.5.10-1, which links against nettle instead of openssl, has
been uploaded to unstable.  It should now be possible for gnutls to
depend on libunbound2 if necessary.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#842874: ITP: python-btrees -- scalable persistent object containers for Python

[Julien Muchembled]

Package: wnpp
Severity: wishlist
Owner: Julien Muchembled 

* Package name: python-btrees
  Version : 4.3.1-1
  Upstream Author : Zope Foundation and Contributors 
* URL : https://github.com/zopefoundation/BTrees
* License : Zope-2.1
  Programming Lang: Python
  Description : scalable persistent object containers for Python

 This package contains a set of persistent object containers built around a
 modified BTree data structure. The trees are optimized for use inside ZODB's
 “optimistic concurrency” paradigm, and include explicit resolution of
 conflicts detected by that mechanism.

This is a required dependency for the new version of ZODB, and I plan to
maintain it as part of the Debian Python Modules Team. See also

 
https://lists.debian.org/msgid-search/8e7791a6-97fd-6a68-8bc2-dee31266c...@jmuchemb.eu

Bug#842873: dak: Rename ACCEPT(ED).* for rejected policy queue uploads

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertag: dak

Quoting from https://lists.debian.org/debian-backports/2016/11/msg1.html:

| The upload is "new" as the override for the package was lost in time and
| space.  I looked at the logs to find out why this happened:
|
|  - 20160619: uploaded to backports-new, overrides are added and the
|package is marked to be accepted, but dak ends up rejecting the
|package (Built-Using refers to another backported package that is not
|yet accepted).
|  - 20160704: unused override gets removed
|  - 20160725: package gets re-uploaded and accepted (as the package is
|still marked to be accepted from 20160619).
|
| So dak treats packages that are to be accepted, but rejected for other
| reasons, and later re-uploaded using the same version wrong.  It should
| probably remove the "accept" mark in this case.

ACCEPT.*, ACCEPTED.* should probably be renamed to something no longer
processed, e.g. ACCEPT-ERROR.*, in case an upload marked to be accepted
ends up getting rejected instead.

Or move ACCEPT.* to the database instead. And/or change how overrides
work ;)

Ansgar

Bug#842872: dak: logs override change, even though there is none

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertag: dak

dak logs an override change with every update of testing:

+---
| 20161101020255|check-overrides|dak|syncing 
override|testing|main|dsc|golang-github-fatih-color|source|misc|None|source|misc|None
+---

Even though the override shouldn't change all the time (and looks the
same in the log message).  This also spams the `audit.package_changes` table.

This doesn't happen for the binary package (golang-github-fatih-color-dev).

Ansgar

Bug#842871: RM: libmsn -- ROM; libmsn provides access to the MSN network, which was officially shutdown in October 2014. Since Oct 18th, kopete, the last rdepends, no longer build-depends on libmsn. T

[Pau Garcia i Quiles]

Package: ftp.debian.org
Severity: normal

Bug#842620: closed by James Cowgill <jcowg...@debian.org> (Re: Bug#842620: mpv: OSD is gone‽)

[Salvo Tomaselli]

Well your workaround doesn't really help. I still need to put the
mouse on the bottom, while before, to see how long was left, i could
just move the mouse slightly.

2016-11-01 21:51 GMT+01:00 Debian Bug Tracking System :
> This is an automatic notification regarding your Bug report
> which was filed against the mpv package:
>
> #842620: mpv: OSD is gone‽
>
> It has been closed by James Cowgill .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact James Cowgill 
>  by
> replying to this email.
>
>
> --
> 842620: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842620
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Messaggio inoltrato --
> From: James Cowgill 
> To: 842620-d...@bugs.debian.org
> Cc:
> Date: Tue, 1 Nov 2016 20:49:11 +
> Subject: Re: Bug#842620: mpv: OSD is gone‽
> On 30/10/16 21:04, James Cowgill wrote:
>> On 30/10/16 20:50, Salvo Tomaselli wrote:
>>> Package: mpv
>>> Version: 0.21.0-2
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>> after upgrade, the osd that appears when moving the mouse seems to be gone.
>>
>> Try moving your mouse to the bottom of the window.
>>
>> In mpv 0.21 the default OSD layout was changed from 'box' to
>> 'bottombar'. You can get the old behavior by using:
>>
>>  mpv --script-opts=osc-layout=box
>
> Closing as this is really a support request.
>
> If my suggestions don't work for you, then please reply to the bugreport
> and I'll reopen it.
>
> Thanks,
> James
>
>
>
> -- Messaggio inoltrato --
> From: Salvo Tomaselli 
> To: Debian Bug Tracking System 
> Cc:
> Date: Sun, 30 Oct 2016 21:50:59 +0100
> Subject: mpv: OSD is gone‽
> Package: mpv
> Version: 0.21.0-2
> Severity: normal
>
> Dear Maintainer,
> after upgrade, the osd that appears when moving the mouse seems to be gone.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.8.2a (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mpv depends on:
> ii  libasound2  1.1.2-1
> ii  libass5 0.13.4-1
> ii  libavcodec577:3.1.5-1
> ii  libavdevice57   7:3.1.5-1
> ii  libavfilter67:3.1.5-1
> ii  libavformat57   7:3.1.5-1
> ii  libavutil55 7:3.1.5-1
> ii  libbluray1  1:0.9.3-2
> ii  libc6   2.24-5
> ii  libcdio-cdda1   0.83-4.2+b1
> ii  libcdio-paranoia1   0.83-4.2+b1
> ii  libcdio13   0.83-4.2+b1
> ii  libdrm2 2.4.71-1
> ii  libdvdnav4  5.0.3-2
> ii  libdvdread4 5.0.3-2
> ii  libegl1-mesa [libegl1-x11]  12.0.3-3
> ii  libenca01.19-1
> ii  libgbm1 12.0.3-3
> ii  libgl1-mesa-glx [libgl1]12.0.3-3
> ii  libguess1   1.2-1.1
> ii  libjack-jackd2-0 [libjack-0.116]1.9.10+20150825git1ed50c92~dfsg-3
> ii  libjpeg62-turbo 1:1.5.1-2
> ii  liblcms2-2  2.7-1
> ii  liblua5.2-0 5.2.4-1.1+b1
> ii  libpulse0   9.0-4
> ii  librubberband2  1.8.1-6+b1
> ii  libsdl2-2.0-0   2.0.4+dfsg2-1
> ii  libsmbclient2:4.4.6+dfsg-2
> ii  libsndio6.1 1.1.0-2
> ii  libswresample2  7:3.1.5-1
> ii  libswscale4 7:3.1.5-1
> ii  libv4l-01.10.1-1
> ii  libva-drm1  1.7.2-1
> ii  libva-wayland1  1.7.2-1
> ii  libva-x11-1 1.7.2-1
> ii  libva1  1.7.2-1
> ii  libvdpau1   1.1.1-5
> ii  libwayland-client0  1.11.0-2
> ii  libwayland-cursor0  1.11.0-2
> ii  libwayland-egl1-mesa [libwayland-egl1]  12.0.3-3
> ii  libx11-62:1.6.3-1
> ii  libxext62:1.3.3-1
> ii  libxinerama12:1.1.3-1+b1
> ii  libxkbcommon0   0.6.1-1
> ii 

Bug#842870: ITP: zodbpickle -- Fork of pickle module, for ZODB

[Julien Muchembled]

Package: wnpp
Severity: wishlist
Owner: Julien Muchembled 

* Package name: zodbpickle
  Version : 0.7.0~1.gc9e09e3-1
  Upstream Author : Zope Foundation and Contributors 
* URL : https://github.com/zopefoundation/zodbpickle
* License : Python, Zope-2.1
  Programming Lang: Python
  Description : Fork of pickle module, for ZODB

 This package presents a uniform pickling interface for ZODB:
 .
 Under Python 2, this package forks both Python 2.7’s pickle and cPickle
 modules, adding support for the protocol 3 opcodes. It also provides a new
 subclass of bytes, zodbpickle.binary, which Python2 applications can use to
 pickle binary values such that they will be unpickled as bytes under Python 3.
 .
 Under Python 3, this package forks the pickle module (and the supporting C
 extension) from both Python 3.2 and Python 3.3. The fork adds support for the
 noload operations used by ZODB.

This is a required dependency for the new version of ZODB, and I plan to
maintain it as part of the Debian Python Modules Team. See also

 
https://lists.debian.org/msgid-search/8e7791a6-97fd-6a68-8bc2-dee31266c...@jmuchemb.eu

Bug#841919: [Letsencrypt-devel] Bug#841919: Bug#841919: acme-tiny: Please provide a backport for jessie

[Jeremías Casteglione]

Hi Mattia:

On Tue, 1 Nov 2016 21:56:23 +
Mattia Rizzolo  wrote:

> Hi! :)
> 
> On Tue, Nov 01, 2016 at 06:39:42PM -0300, Jeremías Casteglione wrote:
> > > It would be nice to have a backported package of acme-tiny for
> > > Jessie.  
> > 
> > I just pushed to package's repo the debian/stable branch, with the
> > backported version 20160801-1~bpo8+1.  
> [..]
> > This is my very first backport so it might be not so well done yet...
> > I'll be uploading it to backports.d.o soon I hope.  
> 
> I guess you need a sponsor for this too, right? :)

Yes, please? =)

> 
> What I noticed:
> 
> * I discurage using "debian/stable" as a branch name in git:
>   + such naming should be reserved to stable uploads, which this isn't
> (being a backport)
>   + "stable" changes over the history, if anything this should say
> "jessie"
>   + summing up: please call that branch either
> "debian/jessie-backports" (this would follow DEP-11) or
> "jessie-backports"

Great, thanks! I just pushed the debian/jessie-backports branch.

I guess it's OK to delete debian/stable branch in alioth's repo then? To
avoid confusions and such?

> * Uploads to backports don't close bugs, so even if you put a Closes:
>   there you'd need to close this bug manually nonetheless

OK, thanks... No problem with that, but I still need to upload it to
backports right? Even if you are going to sponsoring it?

> (on a related note, I also noticed only now that there is no upstream/*
> tags metching the upstream releases; could you please add them too?)

I'm not sure about that... All the commits in the upstream branch were auto
done by git-dpm... And upstream didn't make any release either, really.
That's why we use the timestamp of last commit for the package version and
such.

So not sure about any tags, sorry, but I'm OK to adding whatever is missing
=)

There are actually 3 commits in the upstream branch, one for each "release".
I guess you mean to tag those commits?

> 
> (btw: no need to Cc the ML, it gets all the bug reports messagges
> anyway, being the maintainer)

OK, sure!

Thanks!!


-- 
Jeremías


pgpsMbDruBIye.pgp
Description: OpenPGP digital signature

Bug#842869: dak: logs removing recent unused overrides, even though they are kept

[Ansgar Burchardt]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertag: dak
Severity: minor
Owner: Ansgar Burchardt 

`dak check-overrides` logs the removal of recent unused overrides, even
though they are kept:

+---
| 2016-06.xz:20160620021215|check-overrides|dak|removing unused 
override|jessie-backports|main|dsc|golang-github-fatih-color|extra|misc|None
| 2016-06.xz:20160620021217|check-overrides|dak|removing unused 
override|jessie-backports|main|deb|golang-github-fatih-color-dev|extra|devel|None
| 2016-06.xz:20160620081236|check-overrides|dak|removing unused 
override|jessie-backports|main|dsc|golang-github-fatih-color|extra|misc|None
| 2016-06.xz:20160620081238|check-overrides|dak|removing unused 
override|jessie-backports|main|deb|golang-github-fatih-color-dev|extra|devel|None
[ ... ]
| 2016-07.xz:20160704021044|check-overrides|dak|removing unused 
override|jessie-backports|main|dsc|golang-github-fatih-color|extra|misc|None
| 2016-07.xz:20160704021046|check-overrides|dak|removing unused 
override|jessie-backports|main|deb|golang-github-fatih-color-dev|extra|devel|None
+---

We intentionally keep unused overrides for 14 days to allow buildds to
catch up.

It looks fairly easy to fix: in `dak/check_overrides.py` move the

created < now() - interval '14 days'

condition from the `DELETE` query into the `SELECT` finding unused
overrides (as a `recent` column or so) and only emit log entries when
the override is not recent.

Ansgar

Bug#842868: gip: please make the build reproducible

[Reiner Herrmann]

Source: gip
Version: 1.7.0-1-4
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that gip could not be built reproducibly.
It links objects in a non-deterministic order.

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

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/80-reproducible-build.diff b/debian/patches/80-reproducible-build.diff
new file mode 100644
index 000..b8e89f2
--- /dev/null
+++ b/debian/patches/80-reproducible-build.diff
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/build.sh
 b/build.sh
+@@ -12,7 +12,7 @@
+ REQUIRED_LIBS='gtkmm-2.4 sigc++-2.0'
+ 
+ # Program files.
+-PROGFILES=`find src/ -name "*.cc" -o -name "*.c"`
++PROGFILES=`find src/ -name "*.cc" -o -name "*.c" | LC_ALL=C sort`
+ 
+ # Installation paths. (Plugins will be installed in the LIBDIR)
+ INST_IN_LIBDIR=`find . -name "*.glade"`
diff --git a/debian/patches/series b/debian/patches/series
index e8b6966..69009c4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@
 70-remove-header.diff
 71-debian-hardening.diff
 72-desktop-file.diff
+80-reproducible-build.diff


signature.asc
Description: PGP signature

Bug#810479: Rititle to ITP: paxrat -- PaX exception daemon for Debian packages

[Santiago Ruano Rincón]

Control: retitle -1 ITP: paxrat -- PaX flags management tool
Control: owner -1 "Santiago Ruano Rincón" 

On Fri, 08 Jan 2016 20:44:58 + ban...@openmailbox.org wrote:
> Package: wnpp
> 
> * Package name: paxrat
> Version : 1
> Upstream Author : David McKinney 
> * URL   : https://github.com/subgraph/paxrat
> * License : GPLv3
> Programming Lang: Go
> Description  : PaX exception daemon for Debian packages.
[…]

Hi,

I wanted to give paxrat a try, and I ended up packaging it. A test
package is available at:

deb https://people.debian.org/~santiago/debian santiago-unstable/
deb-src https://people.debian.org/~santiago/debian santiago-unstable

You can find it also in a collab-maint git repo:

https://anonscm.debian.org/collab-maint/paxrat.git

I still need to import post 1.0-tag configuration entries from upstream
git. I hope to do it this week.

Any feedback is welcome.

Cheers,

Santiago


signature.asc
Description: PGP signature

Bug#842867: i3status: please make the build reproducible

[Reiner Herrmann]

Source: i3status
Version: 2.10-2 
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that i3status could not be built reproducibly.
It links objects in non-deterministic order.

The attached patch fixes this by sorting the list.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..762596a
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort objects for deterministic linking order
+
+--- a/Makefile
 b/Makefile
+@@ -67,7 +67,7 @@
+ # YAJL_MAJOR from that file to decide which code path should be used.
+ CFLAGS += -idirafter yajl-fallback
+ 
+-OBJS:=$(wildcard src/*.c *.c)
++OBJS:=$(sort $(wildcard src/*.c *.c))
+ OBJS:=$(OBJS:.c=.o)
+ 
+ ifeq ($(OS),OpenBSD)
diff --git a/debian/patches/series b/debian/patches/series
index 4d1e94a..4cc025f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 kfreebsd-ftbfs.patch
+reproducible-build.patch


signature.asc
Description: PGP signature

Bug#788701: [Pkg-kde-extras] Bug#788701: Debian package orphan

[Mark Purcell]

Hi Maximiliano,

Very happy for this package to remain with kde-extras, I personally don't
have time to maintain it.

Hope it can get some love soon.

Yours Aye,
Mark Purcell

m...@purcell.id.au
04 2822 7764

On 31 Oct. 2016 19:02, "Maximiliano Curia"  wrote:

> ¡Hola Mark!
>
> El 2016-10-31 a las 10:11 +1100, Mark Purcell escribió:
>
>> I no longer maintain this package.
>>
>
> I would suggest you take up the cause as requested at bug #788701.
>>
>
> On 30 Oct. 2016 18:54, "Esokrates"  wrote:
>>
>
>The package "partitionmanager" has not seen any upgrade since years.
>> There have been major releases in that time, see:
>>https://stikonas.eu/wordpress/2016/05/27/kde-partition-manager-2-2-0/
>>
>
>I would be happy to get an reply,
>>
>
> The neon project is maintaining an up to date partition manager:
> https://packaging.neon.kde.org/neon-packaging/partitionmanager.git/
>
> It's usually a good idea to try to sync our packaging efforts with the
> ones in neon.
>
> Also, please, keep the maintenance of the package under the kde extras
> umbrella, so the rest of the team can work on it from time to time.
>
> And, it would be better if the package maintenance is moved to git.
>
> If you need help with any of this, please join to #debian-qt-kde @
> irc.debian.org or ask in the pkg-kde-talk mailing list (
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk )
>
> At least I was planning to work on partition manager after stretch is
> released, so I would prefer if it's not orphaned, but I don't mind if
> somebody else takes care of it.
>
> Happy hacking,
> --
> "I decry the current tendency to seek patents on algorithms. There are
> better
> ways to earn a living than to prevent other people from making use of one's
> contributions to computer science."
> -- Donald Knuth
> Saludos /\/\ /\ >< `/
>

Bug#842866: RM: libweather-com-perl -- ROM; Buggy and unsupported

[Christoph Haas]

Package: ftp.debian.org
Severity: normal

The library is no longer actively maintained. I tried to contact the
upstream developer but got no response. There are open bug reports on
CPAN that are years old which show fundamental problems with the
package and its functionality. I believe it's better to remove it from
Debian.

Bug#842865: atanks: please make the build reproducible

[Reiner Herrmann]

Source: atanks
Version: 6.4~dfsg-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that atanks could not be built reproducibly.
It links object files in non-deterministic order.

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

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..347aa42
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/Makefile
 b/Makefile
+@@ -45,7 +45,7 @@
+ # 
+ # Source files and objects
+ # 
+-SOURCES := $(wildcard src/*.cpp)
++SOURCES := $(sort $(wildcard src/*.cpp))
+ MODULES := $(addprefix obj/,$(notdir $(SOURCES:.cpp=.o)))
+ DEPENDS := $(addprefix dep/,$(notdir $(SOURCES:.cpp=.d)))
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..55077d0
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+reproducible-build.patch


signature.asc
Description: PGP signature

Bug#842846: New ros-vision-opencv transition

[Leopold Palomo-Avellaneda]

El dimarts, 1 de novembre de 2016, a les 19:49:35 CET, Emilio Pozuelo Monfort 
va escriure:
> Control: tags -1 confirmed
> 
> On 01/11/16 19:13, Leopold Palomo-Avellaneda wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear Release Team,
> > 
> > I'm filing this bug for a new transition of ros-vision-opencv. It is
> > in experimental. It builds on all architectures in testing, where it built
> > previously.
> 
> Go ahead.
> 
> BTW I'm happy if you skip the transition bug when only a small number of
> rdeps are involved and you maintain all of them (like in this case). Of
> course if you want to file the bug and wait for an ack, that is fine too!
> 
Thx,

just following the normal procedure. Although I agree that it's a bit heavy in 
these cases.

Cheers,

Leopold


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


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

Bug#828399: libmsn has no rdeps and is useless?

[Pau Garcia i Quiles]

Agreed.

The only rdepends on libmsn was kopete. On June 20th I asked the
maintainer to remove the dependency so that I could safely remove
libmsn. I never got an answer but I have checked now and since October
18th, kopete no longer depends on libmsn.

NB: The MSN network was working on some countries until very recently,
although it was officially shut down years ago.



On Tue, Nov 1, 2016 at 3:42 PM, Andreas Henriksson  wrote:
> Control: tags -1 + wontfix
>
> Hello!
>
> While libmsn does seem to be listed as a "key package" because
> of popcon, the package (since testing/stretch) seems to be of
> questionable use.
>
> It doesn't seem to have any rdeps in testing or unstable.
> Apparently the service it interacts with is non-functional.
>
> Given the key-package status this package will not be auto-removed
> so would be useful if the maintainer could file for manual removal
> if the above information is correct.
>
> Best way I can think of to avoid others wasting time on
> investigating porting this package to openssl 1.1.0 is
> to tag it wontfix, thus doing so.
>
> Regards,
> Andreas Henriksson



-- 
Pau Garcia i Quiles
http://www.elpauer.org

Bug#841843: printer-driver-escpr: backend can't find PPD file]

[Matteo Croce]

2016-10-28 15:39 GMT+02:00 Brian Potkin :
> Many apologies, Matteo. Because I read bug reports in debian-printing I
> inadvertently sent the mail below there and not to you or the bug.
>
> I have tried everything I can think of to reproduce your issue on Jessie
> and unstable but without success. One last try! There is probably some
> repetition of what we have done before but I am not sure if I was as
> clear as I could have been. If this does not work I am out of ideas.
>
> Set up a new queue with a different PPD:
>
>  lpadmin -p newq -v file:/dev/null -E -m 
> escpr:/0/cups/model/epson-inkjet-printer-escpr/Epson-WF-100_Series-epson-escpr-en-ppd
>
> Without any symlinking print to the queue in any way you choose and look
> at the error log. Is "Cannot get option of PIPS" still there?

I get this:

# lpadmin -p newq -v file:/dev/null -E -m
escpr:/0/cups/model/epson-inkjet-printer-escpr/Epson-WF-100_Series-epson-escpr-en-ppd
lpadmin: Unable to open PPD "/tmp/045f3581fdf83": Missing
PPD-Adobe-4.x header on line 0.

maybe the device name is wrong?

# lpinfo -m |grep -i WF-100
escpr:0/cups/model/epson-inkjet-printer-escpr/Epson-WF-100_Series-epson-escpr-en.ppd
EPSON WF-100 Series , Epson Inkjet Printer Driver (ESC/P-R) for Linux

I've retried with this device:

# lpadmin -p newq -v file:/dev/null -E -m
escpr:0/cups/model/epson-inkjet-printer-escpr/Epson-WF-100_Series-epson-escpr-en.ppd

> Alternatively:
>
>  cupsfilter -p /etc/cups/ppd/newq.ppd -d newq -m printer/foo -e 
> /etc/nsswitch.conf > file.out 2> newq.log
>
> Does newq.log contain lines like this?
>
>  gstoraster (PID n) exited with no errors.
>  epson-escpr-wrapper (PID n) exited with no errors.

# grep 'exited with no errors' newq.log
INFO: texttopdf (PID 18625) exited with no errors.
INFO: pdftopdf (PID 18626) exited with no errors.
INFO: gstoraster (PID 18627) exited with no errors.
INFO: epson-escpr-wrapper (PID 18628) exited with no errors.

> (Forget about the command
>
>  /usr/lib/cups/filter/epson-escpr-wrapper 1 1 1 1 1 wf2530.ras > wf2530.data
>
> and its strace output. Another mistake on my part. It worked because I
> had made the symlink you suggested).
>
> Cheers,
>
> Brian.
>
>
>
> - Forwarded message from Brian Potkin  -
>
> Date: Wed, 26 Oct 2016 19:19:55 +0100
> From: Brian Potkin 
> To: debian-print...@lists.debian.org
> Subject: Re: Bug#841843: printer-driver-escpr: backend can't find PPD file
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> On Wed 26 Oct 2016 at 19:58:08 +0200, Matteo Croce wrote:
>
>> Yes it prints.
>> But here it seems I have two separate issues:
>>
>> 1) can't print without symlinking
>> /etc/cups/ppd/usr/lib/cups/filter/epson-escpr-wrapper.ppd to
>> /etc/cups/ppd/Epson_2530.ppd
>
> Everything I said before was on the basis that you did not make that
> symlink for doing the tests I described. If the log below was obtained
> when the cupsfilter command was used after symlinking it is invalid.
>
> Did the /usr/lib/cups/filter/epson-escpr-wrapper command get the symlink
> made in /tmp without your altering the system? Please let me know if I
> am not being clear on what to do.
>
>> 2) can't print from another cpus server and a raw queue.
>
> Sounds like a different issue. Let's stick with this one for now.
>
>> 2016-10-26 19:51 GMT+02:00 Brian Potkin :
>> > On Wed 26 Oct 2016 at 19:04:56 +0200, Matteo Croce wrote:
>> >
>> >> 2016-10-26 18:55 GMT+02:00 Brian Potkin :
>> >> > On Wed 26 Oct 2016 at 12:25:36 +0200, Matteo Croce wrote:
>> >> >
>> >> >> 2016-10-24 23:58 GMT+02:00 Brian Potkin :
>> >> >> > On Mon 24 Oct 2016 at 19:46:51 +0200, Matteo Croce wrote:
>> >> >> > My print queue was set up (all on one line) with
>> >> >> >
>> >> >> >   lpadmin -p wf2530 -v file:/home/brian/wf2530 -E
>> >> >> > -m 
>> >> >> > escpr:/0/cups/model/epson-inkjet-printer-escpr/Epsom-WF-2530_Series-epson-escpr-en-ppd
>> >> >> >
>> >> >> > and I printed with
>> >> >> >
>> >> >> >   lp -d wf2530 /etc/nsswitch.conf
>> >> >> >
>> >> >> > You could try this to see whether it gets printing going for you.
>> >> >>
>> >> >> I get the same error.
>> >> >> I managed to print with:
>> >> >>
>> >> >> # mkdir -p /etc/cups/ppd/usr/lib/cups/filter
>> >> >> # ln -s /etc/cups/ppd/Epson_2530.ppd
>> >> >> /etc/cups/ppd/usr/lib/cups/filter/epson-escpr-wrapper.ppd
>> >> >> # lp -d Epson_2530 /etc/nsswitch.conf
>> >> >
>> >> > This is indeed a step forward and a possible clue.
>> >> >
>> >> >  cupsfilter -p /etc/cups/ppd/wf2530.ppd -m application/vnd.cups-raster 
>> >> > /etc/nsswitch.conf > wf2530.ras 2>log
>> >> >
>> >> > produces a raster file for me. I would expect it to do the same for you.
>> >> >
>> >> >  /usr/lib/cups/filter/epson-escpr-wrapper 1 1 1 1 1 wf2530.ras > 
>> >> > wf2530.data
>> >> >
>> >> > produces a printer ready file from the raster file for me. From what you
>> >> > relate 

Bug#842864: aewan: please make the build reproducible

[Reiner Herrmann]

Source: aewan
Version: 1.0.01-4
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that aewan could not be built reproducibly.
It links object files in a non-deterministic order.

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

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/Makefile.in b/Makefile.in
index 5aac058..3fd224b 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -29,7 +29,7 @@
 # License para obter mais detalhes (uma cópia acompanha este
 # programa, armazenada no arquivo COPYING).
  
-sources=$(wildcard *.c) $(wildcard aewl/*.c) $(wildcard bores/*.c)
+sources=$(sort $(wildcard *.c) $(wildcard aewl/*.c) $(wildcard bores/*.c))
 headers=$(wildcard *.h) $(wildcard bores/*.h) $(wildcard aewl/*.h)
 execs=aewan@EXESUF@ aecat@EXESUF@ aemakeflic@EXESUF@
 mainobjs=$(patsubst %@EXESUF@,%.o,$(execs))


signature.asc
Description: PGP signature

Bug#828393: pull request applied upstream

[Sebastian Andrzej Siewior]

control: tags -1 fixed-upstream
control: forwarded -1 https://github.com/libevent/libevent/pull/397

my understaning is that an updated version of this patch has been merged
upstream. That is

https://github.com/libevent/libevent/commit/3e9e0a0d46e4508e8782ec3787c6d86bab63046d

Sebastian

Bug#823492: [pkg-gnupg-maint] Bug#823492: pinentry-gnome3: does not handle SSH-forwarded X11 connections correctly

[Eduard Bloch]

On Thu, 05 May 2016 17:25:54 +0200 Werner Koch  wrote:
> On Wed,  4 May 2016 20:59, a.rottm...@gmx.at said:
> 
> > gpg-agent was originally spawned on). This is in spite of using
> > "gpg-connect-agent updatestartuptty /bye" from the SSH-spawned shell
> > (which has the correct DISPLAY variable value). This information is
> 
> I use it daily to switch between my laptop's display and my Xserver
> running on my desktop.  It works for me with the GTK and curses
> pinentries.
> 
> Adding "debug-pinentry" to gpg-agent.conf may help with debugging.

This weekend I was trapped by this (or similar) bug and it took a while
to realize what was going wrong (see #842015).

To make it short: pingentry-gtk2 is ok (and so is pinentry-qt) but
pingentry-gnome3 does NOT honor $DISPLAY environment and apparently
talks display :0 only (or maybe where the first local session started? Not
sure).

Easy to reproduce with "Xephyr :1" and 
"ls | DISPLAY=:1 gpg --armor --sign" and guess where the windows will
appear... :-(

In the lack of verbose output by default it's hard to tell from user's
POV what/where the culprit is.

Another buggy behavior I observe sometimes (not sure about repro steps,
maybe only after changing pingentry implemenation with
update-alternatives?!) with pinentry-gnome3 (or maybe
gpg-agent itself?) is that when I push Cancel the gnome dialog comes
again.
I can do so 5 times and then the gnupg-agent hangs. Once this happened,
you can run gpg/gpg-agent again and again and it will just freeze as
soon as passphrase entry is needed. The only workaround seems to be
killing gpg-agent.

This contributes even more to the confusion from the first problem.

Best regards,
Eduard.


signature.asc
Description: PGP signature

Bug#840580: apache2-bin: crashes when issuing a restart while mod_cgid is enabled

[Stefan Fritsch]

Hi,

On Wednesday, 12 October 2016 15:27:45 CET Brendon Baumgartner wrote:
> We have a relatively busy webserver (about 1-2 million hits per day).
> Recently we experienced some downtime and tracked it to mod_cgid. Once we
> disabled this module, the crashes stopped.
> 
> To induce the crash (doesn't always work), enable mod_cgid let the server
> run for a bit. Then issue a restart. In the error log I would find the
> information below. After the crash would occur, apache would no longer
> restart or gracefully kill. I would have to kill -9 two remaining apache
> processes. Once they were gone, I could start the process like normal.

I could not reproduce this. Which command exactly did you use to restart the 
server? 'service apache2 restart' or 'apachectl restart'?

Can you please try to get a more detailed backtrace, as described in /usr/
share/doc/apache2/README.backtrace . Also, besides from the crashing process 
it would be interesting to get backtraces from the two hanging processes. And 
the output from "ps -ef|apache2" from before the restart (to see processes' 
child/parent relationships).

Thanks.

Note that, since you seem to use mpm_prefork, you can use mod_cgi instead of 
mod_cgid if that works better.


Cheers,
Stefan




> 
> 
> [Fri Oct 07 09:24:35.594582 2016] [core:error] [pid 25450] AH00546: no
> record of generation 1 of exiting child 8814 [Fri Oct 07 09:24:35.594659
> 2016] [core:error] [pid 25450] AH00546: no record of generation 1 of
> exiting child 8098 *** stack smashing detected ***: /usr/sbin/apache2
> terminated
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x731af)[0x7f6d8e1c11af]
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f6d8e246aa7]
> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f6d8e246a70]
> /usr/lib/apache2/modules/mod_mpm_prefork.so(+0x4c08)[0x7f6d8b462c08]
> /usr/sbin/apache2(+0x29e450)[0x7f6d8f2a3450]
> === Memory map: 
> 7f6d7f673000-7f6d7f674000 ---p  00:00 0
> 7f6d7f674000-7f6d7fe74000 rw-p  00:00 0
> 7f6d867a8000-7f6d867ad000 r-xp  fe:00 127386
> /usr/lib/apache2/modules/mod_status.so 7f6d867ad000-7f6d869ac000 ---p
> 5000 fe:00 127386
> /usr/lib/apache2/modules/mod_status.so 7f6d869ac000-7f6d869ad000 r--p
> 4000 fe:00 127386
> /usr/lib/apache2/modules/mod_status.so 7f6d869ad000-7f6d869ae000 rw-p
> 5000 fe:00 127386
> /usr/lib/apache2/modules/mod_status.so 7f6d869ae000-7f6d869df000 r-xp
>  fe:00 127385
> /usr/lib/apache2/modules/mod_ssl.so 7f6d869df000-7f6d86bdf000 ---p 00031000
> fe:00 127385 /usr/lib/apache2/modules/mod_ssl.so
> 7f6d86bdf000-7f6d86be1000 r--p 00031000 fe:00 127385
> /usr/lib/apache2/modules/mod_ssl.so 7f6d86be1000-7f6d86be2000 rw-p 00033000
> fe:00 127385 /usr/lib/apache2/modules/mod_ssl.so
> 7f6d86be2000-7f6d86be4000 rw-p  00:00 0
> 7f6d86be4000-7f6d86c55000 rw-p  00:00 0
> 7f6d86c75000-7f6d86c87000 rw-s  00:04 230335829 
> /dev/zero (deleted) 7f6d86c87000-7f6d86cbc000 r--s  fe:03 2051 
>  /var/cache/nscd/services 7f6d86e6-7f6d86e65000 r-xp
>  fe:00 127793
> /usr/lib/apache2/modules/mod_socache_shmcb.so 7f6d86e65000-7f6d87064000
> ---p 5000 fe:00 127793
> /usr/lib/apache2/modules/mod_socache_shmcb.so 7f6d87064000-7f6d87066000
> r--p 4000 fe:00 127793
> /usr/lib/apache2/modules/mod_socache_shmcb.so 7f6d87066000-7f6d87067000
> rw-p 6000 fe:00 127793
> /usr/lib/apache2/modules/mod_socache_shmcb.so 7f6d87067000-7f6d8706a000
> r-xp  fe:00 127658
> /usr/lib/apache2/modules/mod_setenvif.so 7f6d8706a000-7f6d87269000 ---p
> 3000 fe:00 127658
> /usr/lib/apache2/modules/mod_setenvif.so 7f6d87269000-7f6d8726a000 r--p
> 2000 fe:00 127658
> /usr/lib/apache2/modules/mod_setenvif.so 7f6d8726a000-7f6d8726b000 rw-p
> 3000 fe:00 127658
> /usr/lib/apache2/modules/mod_setenvif.so 7f6d8726b000-7f6d8727b000 r-xp
>  fe:00 127579
> /usr/lib/apache2/modules/mod_rewrite.so 7f6d8727b000-7f6d8747a000 ---p
> 0001 fe:00 127579
> /usr/lib/apache2/modules/mod_rewrite.so 7f6d8747a000-7f6d8747b000 r--p
> f000 fe:00 127579
> /usr/lib/apache2/modules/mod_rewrite.so 7f6d8747b000-7f6d8747c000 rw-p
> 0001 fe:00 127579
> /usr/lib/apache2/modules/mod_rewrite.so 7f6d8747c000-7f6d8747f000 r-xp
>  fe:00 121863
> /lib/x86_64-linux-gnu/libkeyutils.so.1.5 7f6d8747f000-7f6d8767e000 ---p
> 3000 fe:00 121863
> /lib/x86_64-linux-gnu/libkeyutils.so.1.5 7f6d8767e000-7f6d8767f000 r--p
> 2000 fe:00 121863

Bug#842817: yorick-hdf5: FTBFS against HDF5 v1.10

[Thibaut Paumard]

Thanks Gilles.

This is due to hid_t changing from 32bit to 64bit and mapping that to
the correct integer type in Yorick.

I managed a quick fix, need a little more time to upload it.

Regards, Thibaut.

Le 01/11/2016 à 14:16, Gilles Filippini a écrit :
> Source: yorick-hdf5
> Version: 0.8.0-5
> Severity: important
> 
> Hi,
> 
> yorick-hdf5 FTBFS againt HDF5 v1.10 currently in experimental:
> 
>dh_auto_test
> make -j1 check
> make[1]: Entering directory '/<>'
> /usr/lib/yorick/bin/yorick -batch check.i
>  Creating data.h5 with data
> ERROR (h5write) Unable to create group
>   LINE: 785  FILE: /<>/hdf5.i
> yorick: quitting on error in batch mode
> /usr/lib/yorick/Makepkg:159: recipe for target 'check-dll' failed
> make[1]: *** [check-dll] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_test: make -j1 check returned exit code 2
> debian/rules:9: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> Full build log attached.
> 
> Thanks,
> 
> _g.
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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)
> 
> 
> 
> 

-- 
* Dr Thibaut Paumard   | LESIA/CNRS - Table équatoriale (bât. 5)   *
* Tel: +33 1 45 07 78 60   | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17   | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France)   *



smime.p7s
Description: Signature cryptographique S/MIME

Bug#841919: [Letsencrypt-devel] Bug#841919: acme-tiny: Please provide a backport for jessie

[Mattia Rizzolo]

Hi! :)

On Tue, Nov 01, 2016 at 06:39:42PM -0300, Jeremías Casteglione wrote:
> > It would be nice to have a backported package of acme-tiny for Jessie.
> 
> I just pushed to package's repo the debian/stable branch, with the
> backported version 20160801-1~bpo8+1.
[..]
> This is my very first backport so it might be not so well done yet... I'll
> be uploading it to backports.d.o soon I hope.

I guess you need a sponsor for this too, right? :)

What I noticed:

* I discurage using "debian/stable" as a branch name in git:
  + such naming should be reserved to stable uploads, which this isn't
(being a backport)
  + "stable" changes over the history, if anything this should say
"jessie"
  + summing up: please call that branch either
"debian/jessie-backports" (this would follow DEP-11) or
"jessie-backports"
* Uploads to backports don't close bugs, so even if you put a Closes:
  there you'd need to close this bug manually nonetheless

(on a related note, I also noticed only now that there is no upstream/*
tags metching the upstream releases; could you please add them too?)

(btw: no need to Cc the ML, it gets all the bug reports messagges
anyway, being the maintainer)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#842792: [gpsd-dbg] gpsd-dbg does not contain debug symbols for gpsd

[Andre Naujoks]

On 11/01/16 22:21, Bernd Zeimetz wrote:

Hi Andre,


If I am missing anything else, please tell me what it is. Which package
do I have to install in order to get the debug symbols for gpsd? I
really don't know where to look.


actually I failed to realize that upstream changed the strip=no option,
so gpsd needs to be built with nostrip=yes. So there were no debug
symbols :( sorry for that! I'll upload a fixed version!


I was beginning to really doubt myself. :-)

Thanks again for the quick response and the help.

Regards
  Andre



best regards,

bernd

Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

[Norbert Lange]

> I don't think this is reasonable leave it as it.
> I would like to see this changes in 3.8 and this will impact too much
> Debian.
I am not saying to leave it, but to do the bigger change in smaller
steps. You seem to miss, that not only the amd64 package will change,
but any host architecture will aswell. I cant test anything but amd64,
and we might mess thing up for the rest of them, possibly without
noticing

** Example, of what I believe will happen (only for arm64. mips64,
ppc64, sparc64? likewise):
* Now:

arm64 package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a.syms

armhf package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms

armel package contains (would contain on a jessie backport, just my guess):
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

* After adding the g++-multilib dependency:
arm64 package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a.syms
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

armhf package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

armel package contains (would contain on a jessie backport, just my guess):
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

** this will affect packaging, and all this is just a GUESS now. We
would know ALOT better what we need to do if we let the build server
run once.
If we start moving around files, we might miss some, or break the build.

> $ debdiff  /tmp/libclang-common-3.8-dev_3.8.1-12_amd64.deb
> libclang-common-3.8-dev_3.8.1-13_amd64.deb
As said, amd64 is just one architecture, I am talking about all of them.

> You are talking about libclang_rt.asan-i386.so and libclang_rt.asan-i686.so,
> right?
These are the ones that add the new lib32* dependencies, and the ones
that are troublesome for dh_shlibdeps

What would you say, if for now we just remove the dependencies to the
lib32* libraries?
You would have to adjust the filter depending on the architecture
(thats exactly what I dont know to figure out easily for other archs).
eg.:
dh_shlibdeps 
-l/buildllvm/llvm-toolchain-3.9-3.9/debian/tmp//usr/lib/llvm-3.9/lib/
-Xlibclang_rt.asan-i686.so -Xlibclang_rt.asan-i386.so

I added a patchv2 for just this. To me this makes alot of sense anyway
since you dont strictly depend on the host toolchain C/C++ libraries.
For example I am using clang with custom toolchains in the /opt
directory and the C/C++ libraries are picked up from there.
They might make sense as recommendations.

For splitting the archives, I`d like to write down a scheme, but this
will take a few days. The patchv2 should result in the same
dependencies as before, but still have the multilibs included.
Works correctly on amd64 and should compile on all others, some other
archs might end up with additional dependencies (32/64bit C/C++libs)
like the previous patch - which we can fix by expanding the table of
extensions (MULTILIB_EXTS).

Kind Regards,
Norbert

PS.: an older patch for splitting up the libs is attached by Bug
#829441. But I think a different approach would be better


2016-11-01 21:24 GMT+01:00 Sylvestre Ledru :
> Le 01/11/2016 à 19:56, Norbert Lange a écrit :
>>
>> Hi,
>>
>> we absolutely should do this. I believe we have some communication
>> problems, because I brought this up multiple times.
>
> Probably me, sorry :/
>>
>> I am not sure how to solve it, I can think of multiple ways. But it
>> would help if you just apply this path as it is, and let it build for
>> the ~10 architectures. Can you do this somehow, maybe just keep it in
>> experimental?
>
> I don't think this is reasonable leave it as it.
> I would like to see this changes in 3.8 and this will impact too much
> Debian.
>
> So, we should find a proper solution.
> However, I "only" saw the i386 files, not armel or others.
> What should be the result on arm archs?
>
>> First, it 

Bug#841919: [Letsencrypt-devel] Bug#841919: acme-tiny: Please provide a backport for jessie

[Jeremías Casteglione]

Hi:

On Mon, 24 Oct 2016 14:59:11 +0200
Elena ``of Valhalla''  wrote:

> Source: acme-tiny
> Severity: wishlist
> 
> Dear Maintainer,
> 
> It would be nice to have a backported package of acme-tiny for Jessie.

I just pushed to package's repo the debian/stable branch, with the
backported version 20160801-1~bpo8+1.

> If there are no unexpected issues, it is quite likely to be just a
> simple rebuild, since there are no significant dependencies, and this is
> the kind of program that is especially useful on a stable machine.

I didn't have to make any change, the package just built and installed fine
in a Debian Jessie installation.

This is my very first backport so it might be not so well done yet... I'll
be uploading it to backports.d.o soon I hope.

Cheers,


-- 
Jeremías

Bug#842863: linux-image-4.8.0-1-amd64-unsigned: USB dies after short time. ohci-pci: HcDoneHead not written back; disabled

[felipe]

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

Dear Maintainer,

After updating from kernel 4.7 to 4.8 some USB devices die after 2
minutes and do not work until I reboot or change to the previous kernel.

After booting, I check the usb devices with:

# lsusb
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 046d:c051 Logitech, Inc. G3 (MX518) Optical Mouse
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 04e8:61b6 Samsung Electronics Co., Ltd M3 Portable Hard 
Drive 1TB
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Then I open an audio file. It plays for about 2 minutes then stops playing.
I check the devices again:

# lsusb
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 046d:c051 Logitech, Inc. G3 (MX518) Optical Mouse
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 04e8:61b6 Samsung Electronics Co., Ltd M3 Portable Hard 
Drive 1TB
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I notice my usb sound card has disapeared from the list:
Bus 009 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter

I checked dmesg and found the error mesage:
# dmesg
[  235.031304] ohci-pci :00:16.0: HcDoneHead not written back; disabled
[  235.031312] ohci-pci :00:16.0: HC died; cleaning up
[  235.031370] usb 9-1: USB disconnect, device number 2


I found this ubuntu bug report that points to the same problem I have:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630063

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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-1-amd64 
root=UUID=a1b73323-8a0d-46ad-9723-72b1f6ca6962 ro iommu=soft quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[9.633039] Adding 15625212k swap on /dev/sda2.  Priority:-1 extents:1 
across:15625212k FS
[9.633642] EXT4-fs (sdc5): mounted filesystem with ordered data mode. Opts: 
(null)
[9.685480] usbcore: registered new interface driver snd-usb-audio
[9.732280] kvm: Nested Virtualization enabled
[9.732286] kvm: Nested Paging enabled
[   10.148328] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[   10.220045] [drm] ib test on ring 5 succeeded
[   10.732126] [drm] ib test on ring 6 succeeded
[   11.232043] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[   11.244121] [drm] ib test on ring 7 succeeded
[   11.245343] [drm] Radeon Display Connectors
[   11.245345] [drm] Connector 0:
[   11.245346] [drm]   DP-1
[   11.245347] [drm]   HPD4
[   11.245350] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 
0x653c
[   11.245350] [drm]   Encoders:
[   11.245352] [drm] DFP1: INTERNAL_UNIPHY2
[   11.245353] [drm] Connector 1:
[   11.245354] [drm]   HDMI-A-1
[   11.245355] [drm]   HPD5
[   11.245357] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 
0x655c
[   11.245358] [drm]   Encoders:
[   11.245359] [drm] DFP2: INTERNAL_UNIPHY2
[   11.245360] [drm] Connector 2:
[   11.245361] [drm]   DVI-I-1
[   11.245361] [drm]   HPD6
[   11.245364] [drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 
0x658c
[   11.245364] [drm]   Encoders:
[   11.245365] [drm] DFP3: INTERNAL_UNIPHY
[   11.245367] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   11.245367] [drm] Connector 3:
[   11.245368] [drm]   DVI-D-1
[   11.245369] [drm]   HPD1
[   11.245371] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 0x657c 
0x657c
[   11.245372] [drm]   Encoders:
[   11.245373] [drm] DFP4: INTERNAL_UNIPHY1
[   11.516747] snd_hda_codec_hdmi hdaudioC0D0: HDMI ATI/AMD: no speaker 
allocation for ELD
[   11.580357] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is 
invalid, remainder is 245
[   11.580477] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is 

Bug#827061: Please commit to OpenSSL 1.0.2 in stretch now not constantly re-evaluateing

[Sam Hartman]

> "Sebastian" == Sebastian Andrzej Siewior  writes:

Sebastian> On 2016-10-31 11:16:38 [-0400], Sam Hartman wrote:
>> At least one of the clusters of packages I'm involved
>> in--shibboleth and moonshot will require some real upstream
>> porting effort.  That's under way in a time scale that will work
>> for buster, but is very unlikely to meet the stretch freeze
>> timeline.

Sebastian> Do you want me to look into moonshot-gss-eap? The other
Sebastian> moonshot-* package with the RC bug won't be part of
Sebastian> current testing. I didn't find anything that matches
Sebastian> shibboleth.

Hi.
I'm really sorry I didn't get a chance to respond earlier. I was
traveling.
Shibboleth comprises opensaml, xmltooling, heavily depends on
xml-security-c and shibboleth-sp2.
Ferenc Wágner (copied) has been handling the Shibboleth packaging and
has an understanding of where the upstream efforts are.  There's been
discussion on pkg-shibboleth-...@lists.alioth.debian.org.
The area that I tdon't think anyone has examined in the moonshot cluster
is libradsec, which also depends on libevent fairly heavily.

Bug#828440: moonshot-gss-eap: FTBFS with openssl 1.1.0

[Sam Hartman]

> "Sebastian" == Sebastian Andrzej Siewior  writes:

Sebastian> control: tags -1 patch
Sebastian> On 2016-06-26 12:23:04 [+0200], Kurt Roeckx wrote:
>> OpenSSL 1.1.0 is about to released.  During a rebuild of all
>> packages using OpenSSL this package fail to build.  A log of that
>> build can be found at:
>> 
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/moonshot-gss-eap_0.9.5-1_amd64-20160529-1451

Sebastian> this builds now. Do you have anything to verify?

Hi.
I'm sorry I didn't get a chance to respond to your other mail.
upstream has dealt with moonshot-gss-eap and moonshot-ui and I plan to
address the bugs there with a new upstream version.
We'll probably need to build-dep on libssl1.0 until the entire cluster
builds with 1.1; I think having two related libraries in the same
address space use different versions of ssl will be problematic.

Bug#842862: virtualbox-qt: Crashes if screen reader enabled

[Jean-Philippe MENGUAL]

Package: virtualbox-qt
Version: 5.1.8-dfsg-6
Severity: important

Dear Maintainer,

Hi,

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

   * What led up to the situation?

MATE 3.18, Orca 3.22, testing.

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

Hi,

On a Debian testing with upstream repo's package:

1.Install qt-at-spi
2.Enable accessibility in the Desktop.
3.Run VirtualBox.
4.Arrow keys, opening dialogs, crash the graphical interface.
5. Run without Orca running.
6.Arrow keys work. Run again screen reader, it crashes as soon as you press 
an arrow key..

VBoxManage works, VMs as well, but GUI is unusable.

Best regards

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.7.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 virtualbox-qt depends on:
ii  libc6 2.24-5
ii  libgcc1   1:6.2.0-9
ii  libgl1-mesa-glx [libgl1]  12.0.3-3
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5opengl5 5.6.1+dfsg-3+b1
ii  libqt5printsupport5   5.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libqt5x11extras5  5.6.1-2
ii  libstdc++66.2.0-9
ii  libx11-6  2:1.6.3-1
ii  libxcb1   1.12-1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  virtualbox5.1.8-dfsg-6

virtualbox-qt recommends no packages.

virtualbox-qt suggests no packages.

-- no debconf information
VirtualBox GUI VM Selector Window 5.1.8 r111374 linux.amd64 (Oct 18 2016 
15:52:08) release log
00:00:00.920838 Log opened 2016-11-01T21:00:57.694353000Z
00:00:00.920839 Build Type: release
00:00:00.920841 OS Product: Linux
00:00:00.920842 OS Release: 4.7.0-1-amd64
00:00:00.920843 OS Version: #1 SMP Debian 4.7.8-1 (2016-10-19)
00:00:00.920862 DMI Product Name: HP ProBook 6560b
00:00:00.920868 DMI Product Version: A0001D02
00:00:00.920908 Host RAM: 3889MB (3.7GB) total, 2108MB (2.0GB) available
00:00:00.920912 Executable: /usr/lib/virtualbox/VirtualBox
00:00:00.920912 Process ID: 24461
00:00:00.920913 Package type: LINUX_64BITS_DEBIAN_9_0
00:00:00.920938 Qt version: 5.6.1
00:00:00.998043 GUI: UIMediumEnumerator: Medium-enumeration started...
00:00:02.784333 Failed to open "/dev/vboxdrv", errno=13, 
rc=VERR_VM_DRIVER_NOT_ACCESSIBLE
00:00:02.785419 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:00:02.806803 refreshCertificates/#1: 
InMem.Cert.TbsCertificate.T3.Extensions.paItems[#].ExtnValue.NameConstraints.T0.PermittedSubtrees.paItems[#]:
 Unexpected sequence type/flags: 0x2/0x80 (expected 0x10/0x20)
00:00:02.808973 refreshCertificates/#3: Found 1/172 SSL certs we/you trust 
(previously 0/0).

Bug#842861: backport to stable

[W. Martin Borgert]

Package: gajim-triggers
Version: 0.1-1
Severity: wishlist

A backport to stable is useful to get the same Gajim experience
on stable as currently in testing.

Bug#832247: blocked by bug #842855

[Ben Finney]

Control: reopen -1
Control: fixed -1 origami-pdf/2.0.0-1
Control: block -1 by 842855

(This time with the correct control commands.)

On 01-Nov-2016, Antonio Terceiro wrote:
> On Sat, Oct 29, 2016 at 09:18:10AM +1100, Ben Finney wrote:
> > Thank you for fixing the source package. Which is the bug report
> > for fixing the archive?
> 
> #842855

Thank you. I've set this bug report's metadata accordingly; its
resolution depends on resolving #842855 first.

-- 
 \  “Dvorak users of the world flgkd!” —Kirsten Chevalier, |
  `\rec.humor.oracle.d |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#832247: closed by Antonio Terceiro <terce...@debian.org> (Bug#832247: fixed in origami-pdf 2.0.0-1)

[Ben Finney]

Control: reopen -1
Control: block -1 by #842855

On 01-Nov-2016, Antonio Terceiro wrote:
> On Sat, Oct 29, 2016 at 09:18:10AM +1100, Ben Finney wrote:
> > Thank you for fixing the source package. Which is the bug report
> > for fixing the archive?
> 
> #842855

Thank you. I've set this bug report's metadata accordingly; its
resolution depends on resolving #842855 first.

-- 
 \  “Dvorak users of the world flgkd!” —Kirsten Chevalier, |
  `\rec.humor.oracle.d |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#842847: several messages

[Thorsten Glaser]

Helmut Grohne dixit:

>Hi Thorsten,
>
>On Tue, Nov 01, 2016 at 08:17:49PM +, Thorsten Glaser wrote:
>> It got lost when I converted the package to debhelper though???
>> does that look good to you?
>
>Should work. I suggest that you close my bugs when adding that and if it
>still doesn't cross build, I'll reopen the bugs.

OK.

>Let me also suggest using dh_auto_build as it does the right thing.

I don’t like things with auto in its name… it also is likely to
not do it (after all, how should it know which files to compile
with which flags, etc)?

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#842792: [gpsd-dbg] gpsd-dbg does not contain debug symbols for gpsd

[Bernd Zeimetz]

Hi Andre,

> If I am missing anything else, please tell me what it is. Which package
> do I have to install in order to get the debug symbols for gpsd? I
> really don't know where to look.

actually I failed to realize that upstream changed the strip=no option,
so gpsd needs to be built with nostrip=yes. So there were no debug
symbols :( sorry for that! I'll upload a fixed version!

best regards,

bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#793290: libpam-script tries to invoke nonexistent scripts

[Christian Meyer]

Hello there,

I found this bug on bugs.d.o and wondered about it, too.
/var/log/auth.log is complaining about the missing scripts.
>> can not stat /usr/share/libpam-script/pam_script_ses_open
>> can not stat /usr/share/libpam-script/pam_script_auth
>> can not stat /usr/share/libpam-script/pam_script_acct

Journalctl is even worse, it prints out these "messages" with priority 3
("ERROR") in the color red. There are no messages with lower priority on
my system - even when something badly goes wrong.

>> Can one somehow make it stop invoking those scripts?
> I wonder how you got this package. If you don't use it I would recommend
> to remove it.
> If you do need to execute scripts it would be best to create the files or
> symlink them like described in the README.Debian file.

Truely: Do you ALWAYS use all possible scripts?
I created the scripts I need (ses_open and ses_close), but don't need auth, 
acct and passwd.

libpam-script/README.pam_script says:
  The scripts can be symbolic links or not exist at all as the case may
  be.
and
  The scripts must return an exit value of 0 if successful with
  regards to its purpose; else return a non-zero exit value.  The
  pam_script.so module does not interpret non-zero values as anything else
  except as the appropriate failure for the given module-type.

With that in mind I don't want to mess around with "sufficient"-PAM-scripts 
that I don't need,
instead I just want to take care of those things I really want. Of course an 
unneeded "sufficient"
or "optional" script safely should fail with a non-zero exit-code, but for that 
you must have a
smell of how PAM works and it's not friendly for newbies.

IMO a high priority "debug (7)" message or even "info (6)" would be helpfull in 
case you really
"forgot" creating a symlink, but for shure it's no "error" (priority 3) if an 
unneeded file is
missing.

Christian

Bug#837928: Bug#837925: usrmerge: fails to merge with molly-guard installed

[Francois Marier]

On 2016-11-01 at 18:48:51, Jonas Smedegaard wrote:
> I don't know how to be more exact than how I wrote it initially for this 
> bugreport.
> 
> Could you perhaps elaborate on what details you are missing?

You wrote this:

"molly-guard adds wrappers for commands like pm-hibernate and poweroff.

The wrappers are added not using dpkg-divert but as symlinks in /sbin,
where the wrapped commands reside in /usr/sbin."

But the wrappers _are_ added using dpkg-divert:

https://anonscm.debian.org/cgit/collab-maint/molly-guard.git/tree/debian/molly-guard.preinst?id=1a3675db6ae1015c4d6e8367c7132c87fb9f3b31#n25

which looks like this on my machine:

$ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 28 Aug 15 22:16 /sbin/reboot -> 
/lib/molly-guard/molly-guard

So what's wrong with this use of dpkg-divert?

Francois

-- 
https://fmarier.org/

Bug#747839: lcms2: build libiccjpeg packages

[Thomas Weber]

On Thu, May 22, 2014 at 09:25:46AM +0200, Thomas Weber wrote:
> Hi Michael, 
> 
> upstream is unlikely to ship a libiccjpeg library, as lcms2 is agnostic
> with respect to graphic file formats and iccjpeg.c is only about jpeg.
> Do you know how other distributions handle this? I just looked and
> found[1] about Gentoo (in fact, following the link [2] there, I just
> wasted upstream's time asking him - ).
> 
> I'd like to go for a solution that is more general than just Chromium on
> Debian.
> 
> [1] 
> http://phajdan-jr.blogspot.be/2013/11/third-party-libraries-in-chromium.html
> [2] http://sourceforge.net/mailarchive/message.php?msg_id=30221395
> 
>   Thomas

Just to add more information to the bug report: the Gentoo developer who
tried to get libiccjpeg into lcms also tried (and apparently failed) to
get it into libjpeg-turbo:
https://sourceforge.net/p/libjpeg-turbo/mailman/message/30387709/

Thomas

Bug#842786: numix-icon-theme: FTBFS (dpkg-source can't extract orig tarball)

[Ben Hutchings]

Control: severity -1 normal

On Tue, 2016-11-01 at 19:17 +0100, Santiago Vila wrote:
> On Tue, Nov 01, 2016 at 12:13:00PM -0600, Ben Hutchings wrote:
> > Do Debian buildds use overlayfs?
> 
> 
> Yes, I think so. Just look at any build log in buildd.debian.org and
> you will see this:
> 
> Not cleaning session: cloned chroot in use
> 
> This is what happens when sbuild is used with union-type=overlay.
> (When not, you would see at that point how installed packages are
> deinstalled).

'Cloned chroot' doesn't imply that at all.  And most buildds are
running the kernel from stable, which doesn't include overlayfs.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special
case.



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

Bug#828440: moonshot-gss-eap: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

control: tags -1 patch

On 2016-06-26 12:23:04 [+0200], Kurt Roeckx wrote:
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/moonshot-gss-eap_0.9.5-1_amd64-20160529-1451

this builds now. Do you have anything to verify?

> Kurt

Sebastian
>From 50b12a010649c57ca7080cc728c8088abf53f73e Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Tue, 1 Nov 2016 20:41:46 +
Subject: [PATCH] moonshot-gss-eap: add support for openssl 1.1.0

and remain compatible with openssl 1.0.1k.
Functions like DH_set0_pqg() are new accecssors in 1.1.0 and have been
added as a compatibiliry wrapper.
SSL_CTX_set_cert_store() for instance are already available in earlier
openssl version and since SSL struct (among others) are opaque the
accessors are used now.
struct tls_keys contains now the copy of the key / random since the
pointer are not exported anymore and a copy saves a malloc() + free()
operation.
I replaced TLSv1_method with SSLv23_method because the former makes only
TLSv1 available. The latter provides multiple versions of the SSL
protocol and try the highest possible version (currently TLSv1.2).

Signed-off-by: Sebastian Andrzej Siewior 
---
 libeap/src/crypto/crypto_openssl.c   | 178 ++-
 libeap/src/crypto/tls.h  |   8 +-
 libeap/src/crypto/tls_openssl.c  |  91 +++---
 libeap/src/eap_peer/eap_tls_common.c |   2 +
 libeap/src/eap_peer/eap_ttls.c   |   4 +
 5 files changed, 218 insertions(+), 65 deletions(-)

diff --git a/libeap/src/crypto/crypto_openssl.c b/libeap/src/crypto/crypto_openssl.c
index 08c98af..ac33a35 100644
--- a/libeap/src/crypto/crypto_openssl.c
+++ b/libeap/src/crypto/crypto_openssl.c
@@ -34,6 +34,56 @@
 	des_ecb_encrypt((input), (output), *(ks), (enc))
 #endif /* openssl < 0.9.7 */
 
+#if OPENSSL_VERSION_NUMBER < 0x1010
+static EVP_MD_CTX *EVP_MD_CTX_new(void)
+{
+	return EVP_MD_CTX_create();
+}
+
+static void EVP_MD_CTX_free(EVP_MD_CTX *ctx)
+{
+	EVP_MD_CTX_destroy(ctx);
+}
+static int DH_set0_pqg(DH *dh, BIGNUM *p, BIGNUM *q, BIGNUM *g)
+{
+	/* If the fields p and g in d are NULL, the corresponding input
+	 * parameters MUST be non-NULL.  q may remain NULL.
+	 */
+	if ((dh->p == NULL && p == NULL)
+	|| (dh->g == NULL && g == NULL))
+		return 0;
+
+	if (p != NULL) {
+		BN_free(dh->p);
+		dh->p = p;
+	}
+	if (q != NULL) {
+		BN_free(dh->q);
+		dh->q = q;
+	}
+	if (g != NULL) {
+		BN_free(dh->g);
+		dh->g = g;
+	}
+
+	if (q != NULL) {
+		dh->length = BN_num_bits(q);
+	}
+
+	return 1;
+}
+
+static void DH_get0_key(const DH *dh, const BIGNUM **pub_key,
+			const BIGNUM **priv_key)
+{
+	if (pub_key != NULL)
+		*pub_key = dh->pub_key;
+	if (priv_key != NULL)
+		*priv_key = dh->priv_key;
+}
+
+#endif
+
 static BIGNUM * get_group5_prime(void)
 {
 #if OPENSSL_VERSION_NUMBER < 0x00908000
@@ -78,37 +128,45 @@ static int openssl_digest_vector(const EVP_MD *type, int non_fips,
  size_t num_elem, const u8 *addr[],
  const size_t *len, u8 *mac)
 {
-	EVP_MD_CTX ctx;
+	EVP_MD_CTX *ctx;
 	size_t i;
 	unsigned int mac_len;
 
-	EVP_MD_CTX_init();
+	ctx = EVP_MD_CTX_new();
+	if (!ctx) {
+		wpa_printf(MSG_ERROR, "OpenSSL: EVP_MD_CTX_new failed: %s",
+			   ERR_error_string(ERR_get_error(), NULL));
+		return -1;
+	}
 #ifdef CONFIG_FIPS
 #ifdef OPENSSL_FIPS
 	if (non_fips)
-		EVP_MD_CTX_set_flags(, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
+		EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
 #endif /* OPENSSL_FIPS */
 #endif /* CONFIG_FIPS */
-	if (!EVP_DigestInit_ex(, type, NULL)) {
+	if (!EVP_DigestInit_ex(ctx, type, NULL)) {
 		wpa_printf(MSG_ERROR, "OpenSSL: EVP_DigestInit_ex failed: %s",
 			   ERR_error_string(ERR_get_error(), NULL));
-		return -1;
+		goto err;
 	}
 	for (i = 0; i < num_elem; i++) {
-		if (!EVP_DigestUpdate(, addr[i], len[i])) {
+		if (!EVP_DigestUpdate(ctx, addr[i], len[i])) {
 			wpa_printf(MSG_ERROR, "OpenSSL: EVP_DigestUpdate "
    "failed: %s",
    ERR_error_string(ERR_get_error(), NULL));
-			return -1;
+			goto err;
 		}
 	}
-	if (!EVP_DigestFinal(, mac, _len)) {
+	if (!EVP_DigestFinal(ctx, mac, _len)) {
 		wpa_printf(MSG_ERROR, "OpenSSL: EVP_DigestFinal failed: %s",
 			   ERR_error_string(ERR_get_error(), NULL));
-		return -1;
+		goto err;
 	}
 
 	return 0;
+err:
+	EVP_MD_CTX_free(ctx);
+	return -1;
 }
 
 
@@ -145,32 +203,35 @@ int rc4_skip(const u8 *key, size_t keylen, size_t skip,
 #ifdef OPENSSL_NO_RC4
 	return -1;
 #else /* OPENSSL_NO_RC4 */
-	EVP_CIPHER_CTX ctx;
+	EVP_CIPHER_CTX *ctx;
 	int outl;
 	int res = -1;
 	unsigned char skip_buf[16];
 
-	EVP_CIPHER_CTX_init();
-	if (!EVP_CIPHER_CTX_set_padding(, 0) ||
-	!EVP_CipherInit_ex(, EVP_rc4(), NULL, NULL, NULL, 1) ||
-	!EVP_CIPHER_CTX_set_key_length(, keylen) ||
-	!EVP_CipherInit_ex(, NULL, NULL, key, NULL, 1))

Bug#842840: nmu: libavfilter6 reverse-dependencies

[Andreas Cadhalpun]

Control: retitle -1 nmu: libavfilter6 reverse-dependencies
Control: severity -1 normal
Control: tags -1 - moreinfo
Control: reassign -1 release.debian.org

Hi,

On 01.11.2016 20:56, Jonas Smedegaard wrote:
> Quoting Andreas Cadhalpun (2016-11-01 19:21:50)
>> So the effective conflict between libavfilter6 and libavfilter-extra6 
>> can and should be solved by rebuilding all packages depending solely 
>> on libavfilter6.
> 
> Right.
> 
> Seems to be these:
> 
>  * ffdiaporama
>  * ffmpeg2theora
>  * forked-daapd
>  * gstreamer1.0-libav
>  * kodi-bin
>  * libffmpegthumbnailer4v5
>  * libgroove4
>  * libmlt6
>  * obs-plugins
>  * pianobar

This list looks correct, thanks.

>> Aside from this one-time problem, are there any benefits of the 
>> approach to use versioned provides?
> 
> Not sure.  I have not yet explored that.

OK, I think the current shlibs method is good enough.
Thus I'm reassigning this bug to the release team.

Dear release team, please schedule the following binNMUs so that
these packages gain an alternative libavfilter-extra6 dependency
in order to become co-installable with it:
nmu ffdiaporama_1.5-5+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu ffmpeg2theora_0.30-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu forked-daapd_24.1-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu gst-libav1.0_1.10.0-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu kodi_16.1+dfsg1-2+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu ffmpegthumbnailer_2.1.1-0.1+b2 . ANY . unstable . -m "rebuild to add 
alternative libavfilter-extra6 dependency"
nmu libgroove_4.3.0-2+b2 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu mlt_6.2.0-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu obs-studio_0.15.4+dfsg1-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu pianobar_2016.06.02-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"

Best regards,
Andreas

Bug#842847: several messages

[Helmut Grohne]

Hi Thorsten,

On Tue, Nov 01, 2016 at 08:17:49PM +, Thorsten Glaser wrote:
> It got lost when I converted the package to debhelper though???
> does that look good to you?

Should work. I suggest that you close my bugs when adding that and if it
still doesn't cross build, I'll reopen the bugs.

Let me also suggest using dh_auto_build as it does the right thing.

Helmut

Bug#832247: closed by Antonio Terceiro <terce...@debian.org> (Bug#832247: fixed in origami-pdf 2.0.0-1)

[Antonio Terceiro]

On Sat, Oct 29, 2016 at 09:18:10AM +1100, Ben Finney wrote:
> On 28-Oct-2016, Debian Bug Tracking System wrote:
> 
> >* Change Section: to `utils` (Closes: #832247)
> 
> Thank you for fixing the source package. Which is the bug report for
> fixing the archive?

#842855


signature.asc
Description: PGP signature

Bug#841420: Patch to allow build

[Sean Laguna]

 On Sun, 30 Oct 2016 01:32:14 -0300 "Raymond Burkholder 
wrote:

> From
> *http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc2/0002-UBUNTU-SAUCE-no-up-disable-pie-when-gcc-has-it-enabl.patch
*
> +# force no-pie for distro compilers that enable pie by default
> +KBUILD_CFLAGS += $(call cc-option, -fno-pie)
> +KBUILD_CFLAGS += $(call cc-option, -no-pie)
> +KBUILD_AFLAGS += $(call cc-option, -fno-pie)
> +KBUILD_CPPFLAGS += $(call cc-option, -fno-pie)

This fixes the build for me (gcc/g++ 6.2.0-10 from unstable, unpatched
linux kernel 4.8 with pf-kernel 4.8.5 patchset)

This is a pretty serious problem IMO, it should be addressed. PIE by
default seems like a bad idea.

Bug#842853: gcl fails to install on mips64el: data.tar.xz corrupted

[Aurelien Jarno]

On 2016-11-01 20:23, Helmut Grohne wrote:
> Package: gcl
> Version: 2.6.12-45
> Severity: serious
> Justification: not installable
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> While conducing multiarch qa, I noticed that gcl fails to install on
> mips64el:
> 
> | Preparing to unpack .../142-gcl_2.6.12-45_mips64el.deb ...
> | Unpacking gcl (2.6.12-45) ...
> | dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
> data is corrupt
> | dpkg-deb: error: subprocess  returned error exit status 2
> | dpkg: error processing archive 
> /tmp/apt-dpkg-install-lpU46F/142-gcl_2.6.12-45_mips64el.deb (--unpack):
> |  subprocess dpkg-deb --fsys-tarfile returned error exit status 2
> | Errors were encountered while processing:
> |  /tmp/apt-dpkg-install-lpU46F/142-gcl_2.6.12-45_mips64el.deb
> | W: No sandbox user '_apt' on the system, can not drop privileges
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> | Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew install -- 
> gcl exited with exit code 1.
> 
> A dpkg-deb -c on the binary package yields:
> 
> | dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
> data is corrupt
> | tar: A lone zero block at 506776
> | dpkg-deb: error: subprocess  returned error exit status 2
> 
> xz -t data.tar.xz
> 
> | xz: data.tar.xz: Compressed data is corrupt
> 
> Something is seriously broken about the binary package (and possibly the
> buildd that was used to build it).
> 
> This is not the first time that some mips* box produces broken binary
> packages.  mips porters X-Debbugs-Cced. Most likely binNMUing "fixes"
> this problem, but we should really figure out why this is happening.

I have been able to find out the previous corruption, it was on kdenlive
16.08.0-1 [1].


Note that the issue is visible in the build log when the content of each
package is displayed. The issue happened on a different build daemon
(mipsel-manda-02 vs mipsel-aql-01). They are similar hardware (Loongson 3
RS780E boards), but two events is not statistically enough to conclude.

I have just scheduled a binNMU to fix the issue for now. I also have
added the entry to our internal tracker so that we can investigage.

Aurelien
  
[1] 
https://buildd.debian.org/status/fetch.php?pkg=kdenlive=mipsel=16.08.0-1=1471942039
[2] https://wiki.debian.org/MIPSPort#Generic_issues

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


signature.asc
Description: PGP signature

Bug#842522: Fwd: Bug#842522: mpv: Symbol lookup error in libass.so.5

[Трезвый Дворник]

-- Forwarded message --
From: Трезвый Дворник 
Date: 2016-11-01 23:02 GMT+03:00
Subject: Re: Bug#842522: mpv: Symbol lookup error in libass.so.5
To: Sebastian Ramacher 


Hi!

Please let us know the output of ldd -r /usr/lib/x86_64-linux-gnu/liba
> ss.so.5
> and your version of libfreetype6.
>
> Cheers
>

noroot@f555l:~$ ldd -r /usr/lib/x86_64-linux-gnu/libass.so.5
linux-vdso.so.1 (0x7ffcf51a5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3c14eed000)
libfribidi.so.0 => /usr/lib/x86_64-linux-gnu/libfribidi.so.0
(0x7f3c14cd6000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
(0x7f3c14a98000)
libfreetype.so.6 =>
/usr/lib/x86_64-linux-gnu/freetype-infinality/libfreetype.so.6
(0x7f3c147e7000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
(0x7f3c14567000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3c141c7000)
/lib64/ld-linux-x86-64.so.2 (0x55e274105000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7f3c13f9d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f3c13d8)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f3c13b65000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f3c13851000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3
(0x7f3c1362b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f3c133b6000)
undefined symbol: FT_Outline_EmboldenXY (/usr/lib/x86_64-linux-gnu/
libass.so.5)

noroot@f555l:~$ apt-cache policy libfreetype6
libfreetype6:
  Installed: 2.6.3-3+b1
  Candidate: 2.6.3-3+b1
  Version table:
 *** 2.6.3-3+b1 500
500 http://mirror.as43289.net/debian testing/main amd64 Packages
500 http://mirror.as43289.net/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 2.4.2-2.1+squeeze4 500
500 http://snapshot.debian.org/archive/debian-archive/
20150827T091707Z/debian squeeze/main amd64 Packages

Best regards,
Dmitri

Bug#842522: Fwd: Bug#842522: mpv: Symbol lookup error in libass.so.5

[Трезвый Дворник]

-- Forwarded message --
From: Трезвый Дворник 
Date: 2016-11-01 23:25 GMT+03:00
Subject: Re: Bug#842522: mpv: Symbol lookup error in libass.so.5
To: Sebastian Ramacher 


Oh, my fail

noroot@f555l:~$ mpv --version
mpv: symbol lookup error: /usr/lib/x86_64-linux-gnu/libass.so.5: undefined
symbol: FT_Outline_EmboldenXY

noroot@f555l:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libfreetype.so.6 mpv
--version
mpv 0.21.0 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil   55.28.100 (runtime 55.34.100)
   libavcodec  57.48.101 (runtime 57.64.100)
   libavformat 57.41.100 (runtime 57.56.100)
   libswscale  4.1.100 (runtime 4.2.100)
   libavfilter 6.47.100 (runtime 6.65.100)
   libswresample   2.1.100 (runtime 2.3.100)
ffmpeg version: 3.2-1

I'm so sorry
But still, mpv is working with the libass5/0.13.2-1 version.

Can you tell the reason for me to know, i must upgrade the
libfreetype-infinality6 package from 2.4 version to 2.6, am i right?

Best regards,
Dmitri

Bug#842860: IndexError when openint Repositories

[Brent S. Elmer]

Package: synaptic
Version: 0.83+nmu1
Severity: important

Synaptic gives the following error when I go into
Settings->Repositories

# synaptic
ERROR:root:Cannot import UbuntuDrivers: No module named 'UbuntuDrivers'
gpg: lookup_hashtable failed: Unknown system error
gpg: trustdb: searching trust record failed: Unknown system error
gpg: Error: The trustdb is corrupted.
gpg: You may try to re-create the trustdb using the commands:
gpg:   cd ~/.gnupg
gpg:   gpg --export-ownertrust > otrust.tmp
gpg:   rm trustdb.gpg
gpg:   gpg --import-ownertrust < otrust.tmp
gpg: If that does not work, please consult the manual
Traceback (most recent call last):
  File "/usr/bin/software-properties-gtk", line 101, in 
app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options,
file=file)
  File "/usr/lib/python3/dist-
packages/softwareproperties/gtk/SoftwarePropertiesGtk.py", line 183, in
__init__
self.show_keys()
  File "/usr/lib/python3/dist-
packages/softwareproperties/gtk/SoftwarePropertiesGtk.py", line 879, in
show_keys
for key in self.apt_key.list():
  File "/usr/lib/python3/dist-packages/softwareproperties/AptAuth.py", line 81,
in list
name = fields[9]
IndexError: list index out of range


As a result, I cannot change my repositories in Synaptic.



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.3.1
ii  libapt-pkg5.01.3.1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.2.0-9
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgnutls30  3.5.5-4
ii  libgtk-3-0   3.22.2-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpcre2-8-0 10.22-2
ii  libstdc++6   6.2.0-9
ii  libvte-2.91-00.46.0-1
ii  libx11-6 2:1.6.3-1
ii  libxapian30  1.4.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages synaptic recommends:
ii  gksu   2.0.2-9
ii  libgtk2-perl   2:1.2499-1
ii  policykit-10.105-17
ii  rarian-compat  0.8.1-6
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
ii  apt-xapian-index 0.49
pn  deborphan
pn  dwww 
ii  menu 2.1.47
ii  software-properties-gtk  0.96.20.2-1
ii  tasksel  3.36

-- no debconf information

Bug#842859: network-manager: fails to get connection on wifi; restarting n-m helps

[Ian Jackson]

Package: network-manager
Version: 1.4.2-2
Severity: normal

network-manager used to work reliably for me on my netbook (a Dell
XPS-13 with Intel wifi chip).  Some time in the last few months (sorry
I can't be more specific) it has started being flaky.

Symptoms are that the n-m applet keeps twirling, and it eventually
gives up.  I have taken to restarting network-manager with
  /etc/init.d/network-manager restart
which is always immediately effective.  Today I tried, after n-m
had given up, simply using the applet to ask it to connect to the
appropriate network.  It was able to do so immediately.

The problem seems to mostly happen when I resume from suspend.  It
doesn't seem to happen spontaneously while the machine is up.

I will attach the last 250 lines of my syslog and the last 150 lines
of my /var/log/messages in case they are useful.

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

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

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.12-1
ii  init-system-helpers1.45
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.41-1
ii  libc6  2.24-5
ii  libglib2.0-0   2.50.1-1
ii  libgnutls303.5.5-4
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.2-1
ii  libndp01.6-1
ii  libnewt0.520.52.19-1
ii  libnl-3-2003.2.27-1
ii  libnm0 1.4.2-2
pn  libpam-systemd 
ii  libpolkit-agent-1-00.105-17
ii  libpolkit-gobject-1-0  0.105-17
ii  libreadline7   7.0-1
ii  libselinux12.5-3
ii  libsoup2.4-1   2.56.0-1
ii  libsystemd0231-9
ii  libteamdctl0   1.26-1
ii  libuuid1   2.28.2-1
ii  lsb-base   9.20161016
ii  policykit-10.105-17
ii  udev   231-9
ii  wpasupplicant  2.5-2+v2.4-3+b1

Versions of packages network-manager recommends:
ii  crda 3.13-1+b1
ii  dnsmasq-base 2.76-4
ii  iptables 1.6.0-4
ii  iputils-arping   3:20150815-2
ii  isc-dhcp-client  4.3.5~b1-1
pn  modemmanager 
ii  ppp  2.4.7-1+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information
Nov  1 20:13:22 zealot kernel: [31194.853626] Broke affinity for irq 1
Nov  1 20:13:22 zealot kernel: [31194.853634] Broke affinity for irq 8
Nov  1 20:13:22 zealot kernel: [31194.853639] Broke affinity for irq 9
Nov  1 20:13:22 zealot kernel: [31194.853644] Broke affinity for irq 12
Nov  1 20:13:22 zealot kernel: [31194.853649] Broke affinity for irq 14
Nov  1 20:13:22 zealot kernel: [31194.853656] Broke affinity for irq 16
Nov  1 20:13:22 zealot kernel: [31194.853661] Broke affinity for irq 17
Nov  1 20:13:22 zealot kernel: [31194.853670] Broke affinity for irq 51
Nov  1 20:13:22 zealot kernel: [31194.853704] Broke affinity for irq 276
Nov  1 20:13:22 zealot kernel: [31194.853709] Broke affinity for irq 277
Nov  1 20:13:22 zealot kernel: [31194.853717] Broke affinity for irq 281
Nov  1 20:13:22 zealot kernel: [31194.853724] Broke affinity for irq 283
Nov  1 20:13:22 zealot kernel: [31194.854760] smpboot: CPU 3 is now offline
Nov  1 20:13:22 zealot kernel: [31194.876722] ACPI: Low-level resume complete
Nov  1 20:13:22 zealot kernel: [31194.876819] ACPI : EC: EC started
Nov  1 20:13:22 zealot kernel: [31194.876819] PM: Restoring platform NVS memory
Nov  1 20:13:22 zealot kernel: [31194.877616] Enabling non-boot CPUs ...
Nov  1 20:13:22 zealot kernel: [31194.897002] x86: Booting SMP configuration:
Nov  1 20:13:22 zealot kernel: [31194.897003] smpboot: Booting Node 0 Processor 
1 APIC 0x2
Nov  1 20:13:22 zealot kernel: [31194.899759]  cache: parent cpu1 should not be 
sleeping
Nov  1 20:13:22 zealot kernel: [31194.899922] CPU1 is up
Nov  1 20:13:22 zealot kernel: [31194.917029] smpboot: Booting Node 0 Processor 
2 APIC 0x1
Nov  1 20:13:22 zealot kernel: [31194.920077]  cache: parent cpu2 should not be 
sleeping
Nov  1 20:13:22 zealot kernel: [31194.920349] CPU2 is up
Nov  1 20:13:22 zealot kernel: [31194.937045] smpboot: Booting Node 0 Processor 
3 APIC 0x3
Nov  1 20:13:22 zealot kernel: [31194.940284]  cache: parent cpu3 should not be 
sleeping
Nov  1 20:13:22 zealot kernel: [31194.940584] CPU3 is up
Nov  1 20:13:22 zealot kernel: [31194.948096] ACPI: Waking up from system sleep 
state S3
Nov  1 20:13:22 zealot kernel: [31195.734111] xhci_hcd :00:14.0: System 
wakeup disabled by ACPI
Nov  1 20:13:22 zealot kernel: [31195.737300] PM: noirq resume of devices 
complete after 17.135 msecs
Nov  1 20:13:22 zealot kernel: [31195.752794] PM: early resume of devices 
complete after 15.428 msecs
Nov  1 20:13:22 zealot kernel: 

Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

[Sylvestre Ledru]

Le 01/11/2016 à 19:56, Norbert Lange a écrit :

Hi,

we absolutely should do this. I believe we have some communication
problems, because I brought this up multiple times.

Probably me, sorry :/

I am not sure how to solve it, I can think of multiple ways. But it
would help if you just apply this path as it is, and let it build for
the ~10 architectures. Can you do this somehow, maybe just keep it in
experimental?

I don't think this is reasonable leave it as it.
I would like to see this changes in 3.8 and this will impact too much 
Debian.


So, we should find a proper solution.
However, I "only" saw the i386 files, not armel or others.
What should be the result on arm archs?


First, it helps if we know we start with a working build (on all
platforms) before modifying it, and which libraries would normally be
built.
Then I would like to be able to make a list of libraries for all
architectures, since I believe this will differ alot.


$ debdiff  /tmp/libclang-common-3.8-dev_3.8.1-12_amd64.deb 
libclang-common-3.8-dev_3.8.1-13_amd64.deb

[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i386.so
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i686.so
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-preinit-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-preinit-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan_cxx-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan_cxx-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.builtins-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.builtins-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi_diag-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi_diag-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.profile-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.profile-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.safestack-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.safestack-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone-i686.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone_cxx-i386.a
-rw-r--r--  root/root 
/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone_cxx-i686.a


this could be the opportunity to move them into a (or several) dedicated 
packages.


So, we could create:
libclang-sanitizer => with the libraries for the arch
and
libclang-sanitizer-multilib => with the libraries for the other 
supported archs (i386 for amd64, arm* for other I guess)


 I don't think we can use some voodoo-multiarch magic here :/


Also (I brought this up before): I dont know if the shared sanitizer
libraries are actually used anywhere. The static libraries dont make
problems, so if we can drop the shared ones then this is one problem
solved.
You are talking about libclang_rt.asan-i386.so and 
libclang_rt.asan-i686.so, right?


S

Bug#841662: libserver-starter-perl: test suite sometimes times out

[gregor herrmann]

On Sun, 30 Oct 2016 20:03:49 +0200, Niko Tyni wrote:

> Given it fails somewhat regularly on both ci.debian.net and
> tests.reproducible-builds.org, possibly a faster machine would improve
> the chances of reproducing it.  Just getting the log of 'strace -f
> -olog prove -l t/01-starter.t' when it locks up would help tremendously,
> but I ran it for two hours or so like that without a single lockup.

I failed as well on Sunday but today I succeeded.
Attached is the output of

while :; do strace -f -olog prove -l t/04-starter-dir.t t/05-killolddelay.t 
t/06-autorestart.t || break ; done

(I picked those test because there are mentioned as problematic at:
https://rt.cpan.org/Public/Bug/Display.html?id=73711
)

[CPAN RT]
> I get the impression that the test suite is riddled with races that
> are worked around by sprinkling sleep() calls in the test code.

Ack.
 
> Even though it feels like giving up, I suggest either disabling the test
> suite or somehow guarding it with a timeout and making failures non-fatal.

I can't object :/
 
> Perhaps we should devise something very simple instead for a single
> basic test?

Also sounds nice.

But maybe you or someone else can make sense of the strace log.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: When I Look At The World


log.gz
Description: application/gzip


signature.asc
Description: Digital Signature

Bug#842847: several messages

[Thorsten Glaser]

Helmut Grohne dixit:

>for the build architecture. Please consider applying the attached patch

I’ll consider them, but will likely solve it differently.

I used to have this in pax/debian/rules:

-# is ${CC} defined anywhere (other than implicit rules?)
-ifneq (,$(findstring $(origin CC),default undefined))
-# no - then default to gcc (or cross-gcc)
-ifneq (${DEB_BUILD_ARCH},${DEB_HOST_ARCH})
-CC=${DEB_HOST_GNU_TYPE}-gcc
-else
-CC=gcc
-endif
-endif

It got lost when I converted the package to debhelper though…
does that look good to you?

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#798278: node-tape ITPs with different owners

[Lucas Castro]

I'm so sorry doing that,

I've not noticed that already had a ITP for that one,

I'm working on another node-* packages too.
I'll be more careful.

--
Lucas Castro

On 29-10-2016 08:38, Ross Gammon wrote:
> Hi Adrian & Lucas,
>
> I have been working on and off packaging the dependencies for
> node-tape and browserify and kosmtik for a while now.
>
> From my point of view, there are so many Node modules that need
> packaging that I don't mind someone else helping out. So whoever gets
> there first (for node-tape or its dependencies) is welcome to take
> ownership of the ITP or RFP if I was the original owner. I will see
> the bug change ownership, and if I had something half finished I will
> let you know and push what I had somewhere for you. If I don't notice,
> it shouldn't matter, because with npm2deb there isn't much time wasted.
>
> Thanks for noticing the duplication Adrian!
>
> Regards,
>
> Ross
>
>
> On 28/10/16 23:18, Adrian Bunk wrote:
>> Control: forcemerge -1 842327
>>
>> Hi Ross, hi Lucas,
>>
>> you both submitted ITPs for node-tape.
>>
>> Please coordinate and agree who will package node-tape.
>>
>> Thanks
>> Adrian
>>
>




signature.asc
Description: OpenPGP digital signature

Bug#842858: bind9: CVE-2016-8864: A problem handling responses containing a DNAME answer can lead to an assertion failure

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.9.5.dfsg-9
Severity: grave
Tags: security upstream

Hi,

the following vulnerability was published for bind9.

CVE-2016-8864[0]:
|A problem handling responses containing a DNAME answer can lead to an
|assertion failure

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-8864
[1] https://kb.isc.org/article/AA-01434

Regards,
Salvatore

Bug#842853: gcl fails to install on mips64el: data.tar.xz corrupted

[Camm Maguire]

severity 842853 normal
thanks

Thanks for your report!  But this really has nothing to do with gcl, but
the mips64 autobuilder.  Will reassign this later.

Take care,

Helmut Grohne  writes:

> Package: gcl
> Version: 2.6.12-45
> Severity: serious
> Justification: not installable
> User: helm...@debian.org
> Usertags: rebootstrap
>
> While conducing multiarch qa, I noticed that gcl fails to install on
> mips64el:
>
> | Preparing to unpack .../142-gcl_2.6.12-45_mips64el.deb ...
> | Unpacking gcl (2.6.12-45) ...
> | dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
> data is corrupt
> | dpkg-deb: error: subprocess  returned error exit status 2
> | dpkg: error processing archive 
> /tmp/apt-dpkg-install-lpU46F/142-gcl_2.6.12-45_mips64el.deb (--unpack):
> |  subprocess dpkg-deb --fsys-tarfile returned error exit status 2
> | Errors were encountered while processing:
> |  /tmp/apt-dpkg-install-lpU46F/142-gcl_2.6.12-45_mips64el.deb
> | W: No sandbox user '_apt' on the system, can not drop privileges
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> | Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew install -- 
> gcl exited with exit code 1.
>
> A dpkg-deb -c on the binary package yields:
>
> | dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
> data is corrupt
> | tar: A lone zero block at 506776
> | dpkg-deb: error: subprocess  returned error exit status 2
>
> xz -t data.tar.xz
>
> | xz: data.tar.xz: Compressed data is corrupt
>
> Something is seriously broken about the binary package (and possibly the
> buildd that was used to build it).
>
> This is not the first time that some mips* box produces broken binary
> packages.  mips porters X-Debbugs-Cced. Most likely binNMUing "fixes"
> this problem, but we should really figure out why this is happening.
>
> Helmut
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#842857: ITP: node-js-tokens -- Regex that tokenizes JavaScript

[Lucas Castro]

Package: wnpp
Severity: wishlist
Owner: Lucas Castro 

* Package name: node-js-tokens
  Version : 2.0.0
  Upstream Author : Simon Lydell <>
* URL : https://github.com/lydell/js-tokens/blob/master/readme.md
* License : MIT/X
  Description : Regex that tokenizes JavaScript


 js-tokens provides a regex with the g flag that matches JavaScript
 tokens.