Bug#882285: gitweb: Recommends no more existing transitional package lynx-cur

[Axel Beckert]

Package: gitweb
Severity: important
Version: 1:2.15.0-1
User: pkg-lynx-ma...@lists.alioth.debian.org
Usertags: lynx-cur-transition

Dear Maintainer,

your package recommends lynx-cur (alternatively, but without having
"lynx" as alternative) which is a transitional package since
Stretch and recently has been removed from Debian Unstable.

Please change that recommendation to just "lynx".

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#882284: gettext: Recommends no more existing transitional package lynx-cur

[Axel Beckert]

Package: gettext
Version: 0.19.8.1-4
Severity: important
User: pkg-lynx-ma...@lists.alioth.debian.org
Usertags: lynx-cur-transition

Dear Maintainer,

your package recommends lynx-cur (alternatively, but without having
"lynx" as alternative) which is a transitional package since Stretch and
recently has been removed from Debian Unstable.

Please change that recommendation to just "lynx".

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gettext depends on:
ii  dpkg   1.19.0.4
ii  gettext-base   0.19.8.1-4
ii  install-info   6.5.0.dfsg.1-1
ii  libc6  2.25-1
ii  libcroco3  0.6.12-1
ii  libglib2.0-0   2.54.2-1
ii  libgomp1   7.2.0-16
ii  libncurses56.0+20170902-1
ii  libtinfo5  6.0+20170902-1
ii  libunistring2  0.9.7-2
ii  libxml22.9.4+dfsg1-5.1

Versions of packages gettext recommends:
ii  curl  7.56.1-1
ii  lynx-cur  2.8.9dev16-1
ii  wget  1.19.2-1

Versions of packages gettext suggests:
ii  autopoint 0.19.8.1-4
pn  gettext-doc   
pn  libasprintf-dev   
pn  libgettextpo-dev  

-- no debconf information

Bug#882283: man2html: Has package relations with no more existing transitional package lynx-cur

[Axel Beckert]

Package: man2html
Version: 1.6g-9
Severity: important
Tags: sid buster
User: pkg-lynx-ma...@lists.alioth.debian.org
Usertags: lynx-cur-transition

Dear Maintainer,

your package contains two package relations with lynx-cur (1x Suggests +
1x alternative Depends) which is a transitional package since Stretch
and recently has been removed from Debian Unstable.

Please change those package relations to just "lynx".

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#868197: s/mawaw2text/mwaw2text/

[Bela Lubkin]

Bug#882036: gjs: only list actual test failures as expected

[Jeremy Bicha]

Control: tags -1 +pending

Thank you again! Committed to svn.

Jeremy Bicha

Bug#882282: aircrack-ng: FTBFS on kfreebsd-amd64: Bus error on first test

[Aaron M. Ucko]

Source: aircrack-ng
Version: 1:1.2.0~rc4-4
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: kfreebsd

Builds of aircrack-ng for kfreebsd-amd64 (admittedly not a release
architecture) have been failing lately:

  make -C src check
  make[2]: Entering directory '/«PKGBUILDDIR»/src'
  ./aircrack-ng -w ../test/password.lst -a 2 -e Harkonen -q 
../test/wpa2.eapol.cap | grep 'KEY FOUND! \[ 12345678 \]' 
  Bus error
  Makefile:291: recipe for target 'check' failed
  make[2]: *** [check] Error 1

The log doesn't supply additional details, but perhaps you can
reproduce the error on a porter box.  Could you please take a look?

Thanks!

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

Bug#882116: RFS: sqlcl-package/0.1.0 [ITP]

[Lazarus Long]

> "sql.standalone" take advantage of Debian's alternatives system and, when

Sorry about that, it should read "sqlcl.standalone". I've corrected
the typo and re-uploaded the package.

Thank you for your compreension,

--
Lazarus Long

Bug#882281: tor: KeepBindCapabilities fails because package is not built with libcap

[John Brooks]

Package: tor
Version: 0.3.1.8-2~d80.jessie+1
Severity: normal

Dear Maintainer,

The tor package for Debian is compiled without capability support, which
prevents KeepBindCapabilities from working.

KeepBindCapabilities instructs Tor to keep CAP_NET_BIND_SERVICE, so that it can
re-bind to low ports after hibernation or changing the config file. This feature
was discussed in #700179 and ultimately implemented, but the Debian package must
be built with libcap for it to work.

Setting KeepBindCapabilities to 1 with the current Debian package causes this
message at startup:

[warn] KeepBindCapabilities set, but no capability support on this system.

To fix this, the package needs to be built with libcap-dev installed on the
build machine. I'm not sure how this is accomplished; perhaps it needs to be
added to Build-Depends.

This seems to affect the package in both the Debian repositories and the
official Tor Project repository at http://deb.torproject.org/torproject.org.

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

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

-- Configuration Files:
/etc/tor/torrc changed [not included]

-- no debconf information

Bug#882280: ITP: node-npmrc -- Switch between different .npmrc files

[Marcelo Jorge Vieira]

Package: wnpp
Severity: wishlist
Owner: Marcelo Jorge Vieira 
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-npmrc
  Version : 1.1.1
  Upstream Author : Conrad Pankoff  (http://www.fknsrs.biz/)
* URL : https://github.com/deoxxa/npmrc
* License : BSD
  Programming Lang: JavaScript
  Description : Switch between different .npmrc files

If you use a private npm registry, you know the pain of switching between a
bunch of different .npmrc files and manually managing symlinks. Let that be a
problem no more! npmrc is here to save the day, by making it dead simple to
switch out your .npmrc with a specific named version. It also tries to protect
you from your own stupid self by making sure you don't accidentally overwrite
an .npmrc that you actually want to keep.


-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com
https://movimente.me

-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com

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

Bug#870635: [Pkg-mutt-maintainers] Bug#870635: mutt package is not using the official mutt tarball

[Faidon Liambotis]

On Mon, Nov 20, 2017 at 06:59:16PM +, Jonathan Dowland wrote:
> > and given NeoMutt the privilege of using the mutt package to establish
> > itself in Debian and all its derivatives, how about you let mutt
> > package users actually *use* my work for once before you move on.
> 
> For most of the package's life in Debian, mutt has indeed been mutt. We
> can't speak for derivatives, and we can't be responsible for them
> either.

I haven't been involved in the packaging team for a while (largely
because of this drama), and I'm comfortable with whatever plan of action
Antonio decides here, but I'd like to state for the record:

Debian has not been packaging pristine mutt… since forever. Debian has
been carrying a number of invasive, new feature patches (both in the
stock "mutt" package, and even more so in the "mutt-patched" package)
for a number of years. The version right before I got involved in,
1.6.0-1, had 35 patches in debian/patches (6 of which only in
mutt-patched), amounting to 14323 lines total of unified diff (plus
context). Rebasing and maintaining these patches was a PITA, as was
fixing bugs in them, which was my original goal when I started getting
involved.

I wasn't involved during the introduction of those patches, but my
understanding is that these were introduced,because Mutt upstream was
unresponsive and effectively dead. Kevin took over later, and has since
moved the needle considerably, and has merged some of those patches or
added the same features using new and different code.

Other distributions and operating systems did the same, and have been
for many years. NeoMutt was an effort to collect all of those patches
that people were running for years (and their variants), rebase them on
top of each other and on top of latest Mutt, clean them up, track and
fix their bugs, and provide quilt patch series for everyone to consume
again.

Its original stated goal, was not to be a fork, but a collection of
patches that would keep tracking mutt upstream, with an ultimate goal of
merging them back upstream (very similar to our debian/patches
workflow). Their homepage still lists that "not a fork" policy[1].

Ultimately, this did not happen, due largely to social differences
between the two projects, and in the midst of significant pushback by
Kevin, they decided to do more invasive changes, rename their binaries,
documentation etc.

It's all a very sad unfortunate turn of events. It'd be for the benefit
of everyone to have those efforts be merged again and work under the
same roof, but sadly, I don't see this happening anytime soon. Renaming
the package in Debian seems to be inevitable now, so I concur that this
would be a good idea at this point.

That said, Debian users have been relying on some of the features only
present in NeoMutt for more than a decade now and by the time buster
gets released, will be accustomed in even more fancy things shipped by
NeoMutt. I don't see what Debian users would have to gain by Debian
shipping vanilla Mutt again. The NeoMutt project is a healthier one in
every possible aspect anyway: > 1 people working on it, a more vibrant
community, more downstreams, easier to work with, technically and
socially.

Regards,
Faidon

1: https://www.neomutt.org/about.html

Bug#882279: RM: tesseract-ocr-dev -- ROM Transitional package no longer needed

[Jeff Breidenbach]

Package: ftp.debian.org
Severity: normal

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

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Tue, 21 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-21 01:01, Mikulas Patocka wrote:
> > 
> > 
> > On Tue, 21 Nov 2017, Aurelien Jarno wrote:
> > 
> > > On 2017-11-21 00:12, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > > > 
> > > > > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > > > > Package: libc6-amd64
> > > > > > Version: 2.25-1
> > > > > > Severity: critical
> > > > > > Justification: breaks the whole system
> > > > > > 
> > > > > > Dear Maintainer,
> > > > > > 
> > > > > > *** Reporter, please consider answering these questions, where 
> > > > > > appropriate ***
> > > > > > 
> > > > > >* What led up to the situation?
> > > > > > 
> > > > > > I have a x86-64 system with i386 and x32 foreign architectures 
> > > > > > (because I
> > > > > > need to develop software for i386 and x32 architectures).
> > > > > > 
> > > > > >* What exactly did you do (or not do) that was effective (or
> > > > > >  ineffective)?
> > > > > > 
> > > > > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > > > > 
> > > > > >* What was the outcome of this action?
> > > > > > 
> > > > > > Halfway through apt upgrade it failed and I ended up with unusable 
> > > > > > system where
> > > > > > large number of binaries were segfauting on startup without doign 
> > > > > > anything.
> > > > > > 
> > > > > >* What outcome did you expect instead?
> > > > > > 
> > > > > > The upgrade to libc-2.25 should work.
> > > > > > 
> > > > > > 
> > > > > > The reason for the catastrophic failure is this:
> > > > > > 
> > > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > > 
> > > > > I guess you mean you have installed one of the two, not both.
> > > > > 
> > > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > > (because
> > > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it 
> > > > > > is
> > > > > > installed nonetheless because of some dependencies.
> > > > > 
> > > > > Just to be clear, as said in my other email, this *is* technically
> > > > > needed as gcc-multilib is not able to make use of the libc in
> > > > > /lib/x86_64-linux-gnu.
> > > > > 
> > > > > > apt makes sure that all libc packages are upgraded at once to the 
> > > > > > same
> > > > > > version. However, during the upgrade process, the package
> > > > > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, 
> > > > > > we
> > > > > > temporarily have two libcs with different versions on the system, 
> > > > > > and this
> > > > > > mismatch makes most of the x86-64 binaries crash. Due to the 
> > > > > > crashes, the
> > > > > > upgrade doesn't proceed and it doesn't install the correct libc 
> > > > > > version in
> > > > > > /lib/x86_64-linux-gnu/.
> > > > > > 
> > > > > > The result is unusable system.
> > > > > 
> > > > > I have done some tests, and while I confirm that libc6-i386:amd64 is
> > > > 
> > > > The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> > > > Not libc6-i386:amd64.
> > > 
> > > Yes, sorry about that, I really did the test with libc6-amd64:i386, but
> > > mixed it when typing the mail.
> > > 
> > > > I.e. use amd64 Debian Sid base installation, add foreign architectures 
> > > > i386 and x32 and use this /etc/apt/sources.list:
> > > > 
> > > > deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main 
> > > > contrib non-free
> > > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> > > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> > > > 
> > > > > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > > > > Indeed the search path in ld.so is to give higher priority to
> > > > > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > > > > libc6:amd64 in version 2.24 (using force-all), while keeping
> > > > > libc6-amd64:i386 in version 2.25.
> > > > > 
> > > > > The only way to change the priority of the two path is using a
> > > > > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf 
> > > > > or
> > > > > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > > > > this directory.
> > > > 
> > > > On my system, there's a file 
> > > > /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> > > > containing:
> > > > 
> > > > # Legacy biarch compatibility support
> > > > /lib64
> > > > /usr/lib64
> > > > 
> > > > and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> > > > 
> > > > # Legacy biarch compatibility support
> > > > /lib32
> > > > /usr/lib32
> > > > 
> > > > These files are created by the packages libc6-i386:x32 and 
> > > > libc6-amd64:x32. They cause that /lib64 is preferred to 
> > > > /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> > > > linker will prefer /lib/x86_64-linux-gnu/.
> > > 
> > > Those files are installed with the zz_ prefix to make sure they are
> > > 

Bug#882278: ruby-appraisal: New Version Available Upstream: 2.2

[Jeffrey Cliff]

Package: ruby-appraisal
Version: 0.5.1-2
Severity: normal

Dear Maintainer,

Current package dates from Nov 2012.  That's quite awhile ago, and a fair
amount of development has occurred since, leading to
the current released version upstream being 2.2.

2.2 release: https://github.com/thoughtbot/appraisal/releases/tag/v2.2.0

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages ruby-appraisal depends on:
ii  bundler  1.13.6-2
ii  rake 10.5.0-2
ii  ruby 1:2.3.3

ruby-appraisal recommends no packages.

ruby-appraisal suggests no packages.

-- no debconf information

Bug#872813: libmbim FTCBFS: /<>/docs/reference/libmbim-glib/.libs/libmbim-glib-scan: cannot execute binary file: Exec format error

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2017-10-31 23:56 Manuel A. Fernandez Montecelo:

2017-08-21 16:22 Helmut Grohne:


Upon closer inspection, I wondered why it was building documentation in
an arch-any build. It turns out that an arch-only build works just fine
with --disable-gtk-doc. That's not only faster, but also successful for
cross compilation. Please consider applying the attached patch.


Would it be possible to include this patch in the next uploads?  It
would allow to cross-build packages that need it like modemmanager,
quite popular and itself needed for many other basic packages
(network-manager, gnome-control-center).

We could offer to NMU, but since the package seems to be well
maintained, it's probably unneeded.

Still, if we can help to move this forward in any way, please tell.


Uploaded NMU with delayed 10, debdiff attached (but pushing also the
changes to collab-maint).

If you want me to cancel it or delay it further, please tell me;
otherwise, if it's OK, I'd appreciate feedback to reschedule and build
it sooner.


Cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru libmbim-1.14.2/debian/changelog libmbim-1.14.2/debian/changelog
--- libmbim-1.14.2/debian/changelog 2017-10-21 00:47:49.0 +0200
+++ libmbim-1.14.2/debian/changelog 2017-11-21 01:15:38.0 +0100
@@ -1,3 +1,13 @@
+libmbim (1.14.2-2.1) unstable; urgency=medium
+
+  [ Manuel A. Fernandez Montecelo ]
+  * Non-maintainer upload.
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Skip documentation in arch-only build. (Closes: #872813)
+
+ -- Manuel A. Fernandez Montecelo   Tue, 21 Nov 2017 01:15:38 
+0100
+
 libmbim (1.14.2-2) unstable; urgency=medium
 
   * Remove myself as Maintainer and reinstate Thomas Bechtold.
diff -Nru libmbim-1.14.2/debian/rules libmbim-1.14.2/debian/rules
--- libmbim-1.14.2/debian/rules 2017-10-21 00:47:49.0 +0200
+++ libmbim-1.14.2/debian/rules 2017-11-21 01:09:41.0 +0100
@@ -3,10 +3,15 @@
 %:
dh $@
 
+ifeq ($(filter libmbim-glib-doc,$(shell dh_listpackages)),)
+configure_flags += --disable-gtk-doc --disable-gtk-doc-html
+else
+configure_flags += --enable-gtk-doc --enable-gtk-doc-html
+endif
+
 override_dh_auto_configure:
dh_auto_configure -- \
-   --enable-gtk-doc \
-   --enable-gtk-doc-html \
+   $(configure_flags) \
--with-udev \
--libexecdir=/usr/lib/libmbim
 

Bug#882277: atk1.0: please make the build reproducible

[Chris Lamb]

Source: atk1.0
Version: 2.26.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that atk1.0 could not be built reproducibly.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 09:00:00.0 
+0900
--- b/debian/patches/reproducible-build.patch   2017-11-21 09:15:30.053563320 
+0900
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-11-21
+
+--- atk1.0-2.26.1.orig/atk/atk-enum-types.c.template
 atk1.0-2.26.1/atk/atk-enum-types.c.template
+@@ -7,7 +7,7 @@
+ 
+ /*** BEGIN file-production ***/
+ 
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
+--- atk1.0-2.26.1.orig/atk/atk-enum-types.h.template
 atk1.0-2.26.1/atk/atk-enum-types.h.template
+@@ -14,7 +14,7 @@ G_BEGIN_DECLS
+ 
+ /*** BEGIN file-production ***/
+ 
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
--- a/debian/patches/series 2017-11-21 08:49:56.241131737 +0900
--- b/debian/patches/series 2017-11-21 08:55:53.066082124 +0900
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-21 01:01, Mikulas Patocka wrote:
> 
> 
> On Tue, 21 Nov 2017, Aurelien Jarno wrote:
> 
> > On 2017-11-21 00:12, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > > 
> > > > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > > > Package: libc6-amd64
> > > > > Version: 2.25-1
> > > > > Severity: critical
> > > > > Justification: breaks the whole system
> > > > > 
> > > > > Dear Maintainer,
> > > > > 
> > > > > *** Reporter, please consider answering these questions, where 
> > > > > appropriate ***
> > > > > 
> > > > >* What led up to the situation?
> > > > > 
> > > > > I have a x86-64 system with i386 and x32 foreign architectures 
> > > > > (because I
> > > > > need to develop software for i386 and x32 architectures).
> > > > > 
> > > > >* What exactly did you do (or not do) that was effective (or
> > > > >  ineffective)?
> > > > > 
> > > > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > > > 
> > > > >* What was the outcome of this action?
> > > > > 
> > > > > Halfway through apt upgrade it failed and I ended up with unusable 
> > > > > system where
> > > > > large number of binaries were segfauting on startup without doign 
> > > > > anything.
> > > > > 
> > > > >* What outcome did you expect instead?
> > > > > 
> > > > > The upgrade to libc-2.25 should work.
> > > > > 
> > > > > 
> > > > > The reason for the catastrophic failure is this:
> > > > > 
> > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > 
> > > > I guess you mean you have installed one of the two, not both.
> > > > 
> > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > (because
> > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > > installed nonetheless because of some dependencies.
> > > > 
> > > > Just to be clear, as said in my other email, this *is* technically
> > > > needed as gcc-multilib is not able to make use of the libc in
> > > > /lib/x86_64-linux-gnu.
> > > > 
> > > > > apt makes sure that all libc packages are upgraded at once to the same
> > > > > version. However, during the upgrade process, the package
> > > > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > > > > temporarily have two libcs with different versions on the system, and 
> > > > > this
> > > > > mismatch makes most of the x86-64 binaries crash. Due to the crashes, 
> > > > > the
> > > > > upgrade doesn't proceed and it doesn't install the correct libc 
> > > > > version in
> > > > > /lib/x86_64-linux-gnu/.
> > > > > 
> > > > > The result is unusable system.
> > > > 
> > > > I have done some tests, and while I confirm that libc6-i386:amd64 is
> > > 
> > > The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> > > Not libc6-i386:amd64.
> > 
> > Yes, sorry about that, I really did the test with libc6-amd64:i386, but
> > mixed it when typing the mail.
> > 
> > > I.e. use amd64 Debian Sid base installation, add foreign architectures 
> > > i386 and x32 and use this /etc/apt/sources.list:
> > > 
> > > deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
> > > non-free
> > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> > > 
> > > > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > > > Indeed the search path in ld.so is to give higher priority to
> > > > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > > > libc6:amd64 in version 2.24 (using force-all), while keeping
> > > > libc6-amd64:i386 in version 2.25.
> > > > 
> > > > The only way to change the priority of the two path is using a
> > > > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> > > > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > > > this directory.
> > > 
> > > On my system, there's a file 
> > > /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> > > containing:
> > > 
> > > # Legacy biarch compatibility support
> > > /lib64
> > > /usr/lib64
> > > 
> > > and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> > > 
> > > # Legacy biarch compatibility support
> > > /lib32
> > > /usr/lib32
> > > 
> > > These files are created by the packages libc6-i386:x32 and 
> > > libc6-amd64:x32. They cause that /lib64 is preferred to 
> > > /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> > > linker will prefer /lib/x86_64-linux-gnu/.
> > 
> > Those files are installed with the zz_ prefix to make sure they are
> > included last, and therefore after x86_64-linux-gnu.conf. It seems to
> > be missing on your system and is probably the root of your problem. This
> > file is installed by libc6:amd64.
> > 
> > Aurelien
> 
> I have /etc/ld.so.conf.d/x86_64-linux-gnu.conf, it contains 
> # Multiarch support
> /lib/x86_64-linux-gnu
> 

Bug#875927: perl: SIGUNUSED removal in glibc 2.26 changes PL_sig_name / SIG_SIZE

[Dominic Hargreaves]

On Sun, Nov 19, 2017 at 05:01:27PM +0200, Niko Tyni wrote:
> On Sun, Nov 19, 2017 at 02:38:40PM +0100, Aurelien Jarno wrote:
> 
> > Now that we have glibc 2.26 in experimental, can I ask about the status
> > of this issue? Do we have to add Breaks: against the affected perl
> > packages?
> 
> Thanks for the reminder.
> 
> I looked a bit at "fixing" libasync-interrupt-perl, noted that it uses
> SIG_SIZE for other things too and decided I don't want to spend my time
> on that.
> 
> My plan is to use the attached workaround, which should keep the ABI
> regardless of the glibc version. It should probably go to sid soon.
> 
> I don't think Breaks are needed. The issue only happens if the current
> perl gets built with the new glibc. Assuming we upload the workaround
> to sid before glibc 2.26, I think it should be fine.

Hello,

Nothing too much to add, but this sounds like a good idea.
Thanks for taking care of this!

Cheers,
Dominic.

Bug#882276: dovecot-sieve: debian stretch reporting errors with lib95_imap_sieve_plugin.so dovecot undefined symbol

[Lance Zeligman]

Package: dovecot-sieve
Version: 1:2.2.27-3+deb9u1
Severity: normal


Dear Maintainer,


I have recently installed dovecot-sieve and dovecot-managesieved on a 
fresh installation of debian 9 only to find that dovecot-sieve is 
causing some issues with imap.


From what I'm seeing, I'm unable to recieve email and when I go to 
check the dovecot logs location with doveadm I see this error:



doveadm log find
Fatal: Couldn't load required plugin 
/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so: dlopen() failed: 
/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so: undefined symbol: 
command_hook_register


is this an issue you're aware of? If so, do you have a fix already for 
it? Please let me know if there is anything else I can do to assist you 
in solving this if it's not already a known issue.

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Tue, 21 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-21 00:15, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > 
> > > On 2017-11-20 21:58, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Mon, 20 Nov 2017, Samuel Thibault wrote:
> > > > 
> > > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > > (because
> > > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it 
> > > > > > is
> > > > > > installed nonetheless because of some dependencies.
> > > > > 
> > > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not 
> > > > > new, I
> > > > > tried to do it in the past, just to see, with the same kind of effect 
> > > > > as
> > > > > you had.
> > > > > 
> > > > > The question is rather how that got pulled at all. What package thinks
> > > > > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > > > > (which should normally not get pulled either), I can see uc-echo which
> > > > > should rather use foreign dependencies, and :i386 multilib packages
> > > > > which don't really make sense to install either.
> > > > > 
> > > > > I don't remember whether it was tried to make libc6-amd64:i386 
> > > > > conflict
> > > > > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > > > > doesn't happen by misfortune?
> > > > > 
> > > > > Samuel
> > > > 
> > > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, 
> > > > lib64asan3, 
> > > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, 
> > > > lib64itm1, 
> > > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> > > > 
> > > > If you install gcc-7-multilib for non-default architecture (i386 or 
> > > > x32), 
> > > > it will inevitably pull libc6-amd64.
> > > 
> > > What's the point of doing that, as opposed for example building with
> > > -m32 or mx32?
> > 
> > The native x32 gcc binary is about 10% faster than the amd64 binary.
> 
> In that case you can install only gcc-7:x32 instead of gcc-7-multilib:x32,
> which won't pull libc6-amd64:x32.

But then, it won't be able to build i386 and amd64 binaries.

Mikulas

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

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Tue, 21 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-21 00:12, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > 
> > > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > > Package: libc6-amd64
> > > > Version: 2.25-1
> > > > Severity: critical
> > > > Justification: breaks the whole system
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > *** Reporter, please consider answering these questions, where 
> > > > appropriate ***
> > > > 
> > > >* What led up to the situation?
> > > > 
> > > > I have a x86-64 system with i386 and x32 foreign architectures (because 
> > > > I
> > > > need to develop software for i386 and x32 architectures).
> > > > 
> > > >* What exactly did you do (or not do) that was effective (or
> > > >  ineffective)?
> > > > 
> > > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > > 
> > > >* What was the outcome of this action?
> > > > 
> > > > Halfway through apt upgrade it failed and I ended up with unusable 
> > > > system where
> > > > large number of binaries were segfauting on startup without doign 
> > > > anything.
> > > > 
> > > >* What outcome did you expect instead?
> > > > 
> > > > The upgrade to libc-2.25 should work.
> > > > 
> > > > 
> > > > The reason for the catastrophic failure is this:
> > > > 
> > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > 
> > > I guess you mean you have installed one of the two, not both.
> > > 
> > > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > installed nonetheless because of some dependencies.
> > > 
> > > Just to be clear, as said in my other email, this *is* technically
> > > needed as gcc-multilib is not able to make use of the libc in
> > > /lib/x86_64-linux-gnu.
> > > 
> > > > apt makes sure that all libc packages are upgraded at once to the same
> > > > version. However, during the upgrade process, the package
> > > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > > > temporarily have two libcs with different versions on the system, and 
> > > > this
> > > > mismatch makes most of the x86-64 binaries crash. Due to the crashes, 
> > > > the
> > > > upgrade doesn't proceed and it doesn't install the correct libc version 
> > > > in
> > > > /lib/x86_64-linux-gnu/.
> > > > 
> > > > The result is unusable system.
> > > 
> > > I have done some tests, and while I confirm that libc6-i386:amd64 is
> > 
> > The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> > Not libc6-i386:amd64.
> 
> Yes, sorry about that, I really did the test with libc6-amd64:i386, but
> mixed it when typing the mail.
> 
> > I.e. use amd64 Debian Sid base installation, add foreign architectures 
> > i386 and x32 and use this /etc/apt/sources.list:
> > 
> > deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
> > non-free
> > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> > 
> > > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > > Indeed the search path in ld.so is to give higher priority to
> > > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > > libc6:amd64 in version 2.24 (using force-all), while keeping
> > > libc6-amd64:i386 in version 2.25.
> > > 
> > > The only way to change the priority of the two path is using a
> > > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> > > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > > this directory.
> > 
> > On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> > containing:
> > 
> > # Legacy biarch compatibility support
> > /lib64
> > /usr/lib64
> > 
> > and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> > 
> > # Legacy biarch compatibility support
> > /lib32
> > /usr/lib32
> > 
> > These files are created by the packages libc6-i386:x32 and 
> > libc6-amd64:x32. They cause that /lib64 is preferred to 
> > /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> > linker will prefer /lib/x86_64-linux-gnu/.
> 
> Those files are installed with the zz_ prefix to make sure they are
> included last, and therefore after x86_64-linux-gnu.conf. It seems to
> be missing on your system and is probably the root of your problem. This
> file is installed by libc6:amd64.
> 
> Aurelien

I have /etc/ld.so.conf.d/x86_64-linux-gnu.conf, it contains 
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

But nonetheless, the linker prefers libc from /lib64.

I have these files in /etc/ld.so.conf.d:

i386-linux-gnu.conf:# Multiarch support
i386-linux-gnu.conf:/lib/i386-linux-gnu
i386-linux-gnu.conf:/usr/lib/i386-linux-gnu
i386-linux-gnu.conf:/lib/i686-linux-gnu
i386-linux-gnu.conf:/usr/lib/i686-linux-gnu

Bug#882275: RFP : ruby-rails-hamlit -- Hamlit (haml) generators for Rails 4

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
Upstream Author : Meng "mfung" Fung
URL : https://github.com/mfung/hamlit-rails
License : MIT (
https://github.com/mfung/hamlit-rails/blob/master/LICENSE.txt )
Language : ruby
Description : Hamlit-rails Provides hamlit generators for Rails 4. It also
enables hamlit as the templating engine and "hamlit:html2haml" rake task
that converts erb files to haml.

Bug#882249: Welcome to Amazon - congrats Frank fQRU

[frank shkreli]

Stop...

On Monday, November 20, 2017, thank you  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#882274: stretch-pu: package nova/2:14.0.0-4 - using uwsgi-plugin-python for nova-placement-api

[Thomas Goirand]

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

Hi,

I'd like to push for an update of Nova, to fix the nova-placement-api
package. Indeed, /usr/bin/nova-placement-api is *not* a Daemon, but a WSGI
application, that can work for example with libapache-mod-wsgi or others.

As a consequence, the init script for the start of nova-placement-api
simply doesn't work. So I'd like to make use of uwsgi, which is a very
good way to run WSGI applications. I've added a runtime depends on uwsgi,
and modified the startup script to use that. As I've used uwsgi in other
daemons, the modification is just 2 lines in the init template system
of openstack-pkg-tools, as per the attached debdiff.

This update, I'd like to push it in the soon comming security update for
Nova, through a security upload fixing CVE-2017-16239 / #882009. This
update is currently on hold, because the upstream patch adds a DoS hole.
Though the security team (ie: Sebastien Delafond) advised me wisely to
start the discussion with the release team about this new dependency
for nova-placement-api.

So, does the SRM agree to the attached change? (note: I've stripped
out the CVE fix from it)

Cheers,

Thomas Goirand (zigo)
diff -Nru nova-14.0.0/debian/changelog nova-14.0.0/debian/changelog
--- nova-14.0.0/debian/changelog2017-04-02 10:52:50.0 +
+++ nova-14.0.0/debian/changelog2017-11-17 15:41:15.0 +
@@ -1,3 +1,13 @@
+nova (2:14.0.0-4+deb9u1) stretch-security; urgency=medium
+
+  * Fixed nova-placement-api init to use uwsgi. The old init file was simply
+not working at all.
+
+ -- Thomas Goirand   Fri, 17 Nov 2017 15:41:15 +
+
 nova (2:14.0.0-4) unstable; urgency=medium
 
   [ David Rabel ]
diff -Nru nova-14.0.0/debian/control nova-14.0.0/debian/control
--- nova-14.0.0/debian/control  2017-04-02 10:52:50.0 +
+++ nova-14.0.0/debian/control  2017-11-17 15:41:15.0 +
@@ -653,6 +653,7 @@
 Architecture: all
 Depends: debconf,
  nova-common (= ${binary:Version}),
+ uwsgi-plugin-python,
  ${misc:Depends},
  ${ostack-lsb-base},
  ${python:Depends},
diff -Nru nova-14.0.0/debian/nova-placement-api.init.in 
nova-14.0.0/debian/nova-placement-api.init.in
--- nova-14.0.0/debian/nova-placement-api.init.in   2017-04-02 
10:52:50.0 +
+++ nova-14.0.0/debian/nova-placement-api.init.in   2017-11-17 
15:41:15.0 +
@@ -14,3 +14,5 @@
 DESC="OpenStack Compute Placement API"
 PROJECT_NAME=nova
 NAME=${PROJECT_NAME}-placement-api
+DAEMON=/usr/bin/uwsgi_python
+DAEMON_ARGS="--master --die-on-term --logto 
/var/log/nova/nova-placement-api.log --http-socket :8778 --wsgi-file 
/usr/bin/nova-placement-api"

Bug#882246: message for you U6Et

[ANICHE KANU]

Please quit sending this to me.

On Nov 20, 2017 9:56 AM, "congratulations"  wrote:

> Welcome to AmazonRewardsGroup
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: minor Hi, it seems that $PATH is
> set to something different than the Debian default path (as per
> /etc/profile). This patch (also attached) worked for me to get the correct
> and user specific $PATH. --- a/startwm.sh 2017-11-16 00:58:26.560463287
> +0100 +++ b/startwm.sh 2017-11-01 17:56:13.042371563 +0100 @@ -2,6 +2,10 @@
> # xrdp X session start script (c) 2015 mirabilos # published under The
> MirOS Licence +if test -r /etc/profile; then + . /etc/profile +fi + if test
> -r /etc/default/locale; then . /etc/default/locale test -z "${LANG+x}" ||
> export LANG Wolfgang

Bug#839017: cabextract FTCBFS: uses build architecture compiler

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2017-11-04 21:22 Manuel A. Fernandez Montecelo:

Hi,

2016-09-27 23:00 Eric Sharkey:

On Tue, Sep 27, 2016 at 3:32 PM, Helmut Grohne  wrote:

cabextract fails to cross build from source, because it uses the build
architecture compiler. [] Please consider applying the attached
patch.


Thanks,

I'll take a look.


What's the status of this?  Do you think that it's OK to include in the
next uploads?


Uploading NMU now, debdiff attached.


Cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru cabextract-1.6/debian/changelog cabextract-1.6/debian/changelog
--- cabextract-1.6/debian/changelog 2015-04-03 01:36:53.0 +0200
+++ cabextract-1.6/debian/changelog 2017-11-21 00:33:32.0 +0100
@@ -1,3 +1,12 @@
+cabextract (1.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Use dh_auto_configure and dh_auto_install: Closes: #839017
+
+ -- Manuel A. Fernandez Montecelo   Tue, 21 Nov 2017 00:33:32 
+0100
+
 cabextract (1.6-1) unstable; urgency=medium
 
   * New upstream release: Closes: #778753
diff -Nru cabextract-1.6/debian/compat cabextract-1.6/debian/compat
--- cabextract-1.6/debian/compat2015-04-03 01:36:53.0 +0200
+++ cabextract-1.6/debian/compat2017-11-21 00:33:07.0 +0100
@@ -1 +1 @@
-6
+7
diff -Nru cabextract-1.6/debian/control cabextract-1.6/debian/control
--- cabextract-1.6/debian/control   2015-04-03 01:36:53.0 +0200
+++ cabextract-1.6/debian/control   2017-11-21 00:33:07.0 +0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Eric Sharkey 
-Build-Depends: debhelper (>> 6.0.0), sharutils, libmspack-dev
+Build-Depends: debhelper (>= 7), sharutils, libmspack-dev
 Standards-Version: 3.9.6
 
 Package: cabextract
diff -Nru cabextract-1.6/debian/rules cabextract-1.6/debian/rules
--- cabextract-1.6/debian/rules 2015-04-03 01:36:53.0 +0200
+++ cabextract-1.6/debian/rules 2017-11-21 00:33:07.0 +0100
@@ -13,7 +13,7 @@
 configure-stamp:
dh_testdir
# Add here commands to configure the package.
-   ./configure CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" 
LDFLAGS="$(LDFLAGS)" --prefix=$(CURDIR)/debian/cabextract/usr 
--mandir=$(CURDIR)/debian/cabextract/usr/share/man 
--infodir=$(CURDIR)/debian/cabextract/usr/share/info 
--with-external-libmspack=yes
+   dh_auto_configure -- CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" 
LDFLAGS="$(LDFLAGS)" --with-external-libmspack=yes

 
touch configure-stamp
@@ -48,7 +48,7 @@
dh_installdirs
 
# Add here commands to install the package into debian/cabextract.
-   \$(MAKE) install
+   dh_auto_install
cp $(CURDIR)/debian/cabextract.desktop 
$(CURDIR)/debian/cabextract/usr/share/apps/konqueror/servicemenus/
cp $(CURDIR)/debian/cabextract.desktop.kde4 
$(CURDIR)/debian/cabextract/usr/share/kde4/services/ServiceMenus/cabextract.desktop
uudecode -o $(CURDIR)/debian/cabextract/usr/share/icons/cab_extract.png 
$(CURDIR)/debian/cab_extract.png.uu

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-21 00:12, Mikulas Patocka wrote:
> 
> 
> On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> 
> > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > Package: libc6-amd64
> > > Version: 2.25-1
> > > Severity: critical
> > > Justification: breaks the whole system
> > > 
> > > Dear Maintainer,
> > > 
> > > *** Reporter, please consider answering these questions, where 
> > > appropriate ***
> > > 
> > >* What led up to the situation?
> > > 
> > > I have a x86-64 system with i386 and x32 foreign architectures (because I
> > > need to develop software for i386 and x32 architectures).
> > > 
> > >* What exactly did you do (or not do) that was effective (or
> > >  ineffective)?
> > > 
> > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > 
> > >* What was the outcome of this action?
> > > 
> > > Halfway through apt upgrade it failed and I ended up with unusable system 
> > > where
> > > large number of binaries were segfauting on startup without doign 
> > > anything.
> > > 
> > >* What outcome did you expect instead?
> > > 
> > > The upgrade to libc-2.25 should work.
> > > 
> > > 
> > > The reason for the catastrophic failure is this:
> > > 
> > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > 
> > I guess you mean you have installed one of the two, not both.
> > 
> > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > installed nonetheless because of some dependencies.
> > 
> > Just to be clear, as said in my other email, this *is* technically
> > needed as gcc-multilib is not able to make use of the libc in
> > /lib/x86_64-linux-gnu.
> > 
> > > apt makes sure that all libc packages are upgraded at once to the same
> > > version. However, during the upgrade process, the package
> > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > > temporarily have two libcs with different versions on the system, and this
> > > mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> > > upgrade doesn't proceed and it doesn't install the correct libc version in
> > > /lib/x86_64-linux-gnu/.
> > > 
> > > The result is unusable system.
> > 
> > I have done some tests, and while I confirm that libc6-i386:amd64 is
> 
> The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> Not libc6-i386:amd64.

Yes, sorry about that, I really did the test with libc6-amd64:i386, but
mixed it when typing the mail.

> I.e. use amd64 Debian Sid base installation, add foreign architectures 
> i386 and x32 and use this /etc/apt/sources.list:
> 
> deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
> non-free
> deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> 
> > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > Indeed the search path in ld.so is to give higher priority to
> > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > libc6:amd64 in version 2.24 (using force-all), while keeping
> > libc6-amd64:i386 in version 2.25.
> > 
> > The only way to change the priority of the two path is using a
> > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > this directory.
> 
> On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> containing:
> 
> # Legacy biarch compatibility support
> /lib64
> /usr/lib64
> 
> and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> 
> # Legacy biarch compatibility support
> /lib32
> /usr/lib32
> 
> These files are created by the packages libc6-i386:x32 and 
> libc6-amd64:x32. They cause that /lib64 is preferred to 
> /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> linker will prefer /lib/x86_64-linux-gnu/.

Those files are installed with the zz_ prefix to make sure they are
included last, and therefore after x86_64-linux-gnu.conf. It seems to
be missing on your system and is probably the root of your problem. This
file is installed by libc6:amd64.

Aurelien

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

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

Hi,

just realized I sent this using my work address. Here is the correct one
(but I'm subscribed to the bug anyway).


On Sun, 19 Nov 2017 18:45:21 +0100  wrote:
> Hi !
>
> On Tue, 4 Oct 2016 15:30:00 +0100 Jonathan Dowland 
wrote:

> > This is a dependency for LXD and is being packaged via the pkg-go team.
>
> It's actually the last one beside golang-gopkg-lxc-go-lxc.v2-dev.
>
> Any ETA ? I saw the repository under pkg-go, is there any way I can help ?

When I wanted to build the package, I realized it's not using
git-buildpackage, as the other Go packages do.

Is it intentional, or do you plan to use graft or something like that to
rewrite history and have the proper branches ? I had a look at it, and
I'm not really comfortable enough with git
to do it without messing things up, so I wonder what the options are.


Cheers,

-- 
nodens

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-21 00:15, Mikulas Patocka wrote:
> 
> 
> On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> 
> > On 2017-11-20 21:58, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Mon, 20 Nov 2017, Samuel Thibault wrote:
> > > 
> > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > (because
> > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > > installed nonetheless because of some dependencies.
> > > > 
> > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> > > > tried to do it in the past, just to see, with the same kind of effect as
> > > > you had.
> > > > 
> > > > The question is rather how that got pulled at all. What package thinks
> > > > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > > > (which should normally not get pulled either), I can see uc-echo which
> > > > should rather use foreign dependencies, and :i386 multilib packages
> > > > which don't really make sense to install either.
> > > > 
> > > > I don't remember whether it was tried to make libc6-amd64:i386 conflict
> > > > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > > > doesn't happen by misfortune?
> > > > 
> > > > Samuel
> > > 
> > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
> > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, 
> > > lib64itm1, 
> > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> > > 
> > > If you install gcc-7-multilib for non-default architecture (i386 or x32), 
> > > it will inevitably pull libc6-amd64.
> > 
> > What's the point of doing that, as opposed for example building with
> > -m32 or mx32?
> 
> The native x32 gcc binary is about 10% faster than the amd64 binary.

In that case you can install only gcc-7:x32 instead of gcc-7-multilib:x32,
which won't pull libc6-amd64:x32.

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

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Mon, 20 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-20 21:58, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 20 Nov 2017, Samuel Thibault wrote:
> > 
> > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > installed nonetheless because of some dependencies.
> > > 
> > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> > > tried to do it in the past, just to see, with the same kind of effect as
> > > you had.
> > > 
> > > The question is rather how that got pulled at all. What package thinks
> > > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > > (which should normally not get pulled either), I can see uc-echo which
> > > should rather use foreign dependencies, and :i386 multilib packages
> > > which don't really make sense to install either.
> > > 
> > > I don't remember whether it was tried to make libc6-amd64:i386 conflict
> > > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > > doesn't happen by misfortune?
> > > 
> > > Samuel
> > 
> > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
> > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, 
> > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> > 
> > If you install gcc-7-multilib for non-default architecture (i386 or x32), 
> > it will inevitably pull libc6-amd64.
> 
> What's the point of doing that, as opposed for example building with
> -m32 or mx32?

The native x32 gcc binary is about 10% faster than the amd64 binary.

> > If we removed libc6-amd64 at all, it would cause problems building amd64 
> > packages on i386 system. We could make those lib64* packages dependent on 
> > libc6:amd64 instead, but that would break if the user has i386 
> > installation and he doesn't have amd64 foreign architecture set up.
> > 
> > It would be best to set it up so that libc6-amd64 doesn't install any 
> > files only if libc6:amd64 is present. Could it be done with the deb 
> > format?
> 
> It's not something possible, and it's even more complicated than that.
> The current ugly way the multiarch + multilib is done, uses a different
> libc for linking and executing. So you definitely need to install both
> if you want to be able to build and execute code.
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Mikulas

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Mon, 20 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-20 19:13, Mikulas Patocka wrote:
> > Package: libc6-amd64
> > Version: 2.25-1
> > Severity: critical
> > Justification: breaks the whole system
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> > 
> >* What led up to the situation?
> > 
> > I have a x86-64 system with i386 and x32 foreign architectures (because I
> > need to develop software for i386 and x32 architectures).
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > 
> >* What was the outcome of this action?
> > 
> > Halfway through apt upgrade it failed and I ended up with unusable system 
> > where
> > large number of binaries were segfauting on startup without doign anything.
> > 
> >* What outcome did you expect instead?
> > 
> > The upgrade to libc-2.25 should work.
> > 
> > 
> > The reason for the catastrophic failure is this:
> > 
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> 
> I guess you mean you have installed one of the two, not both.
> 
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> Just to be clear, as said in my other email, this *is* technically
> needed as gcc-multilib is not able to make use of the libc in
> /lib/x86_64-linux-gnu.
> 
> > apt makes sure that all libc packages are upgraded at once to the same
> > version. However, during the upgrade process, the package
> > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > temporarily have two libcs with different versions on the system, and this
> > mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> > upgrade doesn't proceed and it doesn't install the correct libc version in
> > /lib/x86_64-linux-gnu/.
> > 
> > The result is unusable system.
> 
> I have done some tests, and while I confirm that libc6-i386:amd64 is

The problem is with libc6-amd64:i386 or libc6-amd64:x32.
Not libc6-i386:amd64.

I.e. use amd64 Debian Sid base installation, add foreign architectures 
i386 and x32 and use this /etc/apt/sources.list:

deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
non-free
deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main

> unpacked much before libc6:amd64, it doesn't cause any issue here.
> Indeed the search path in ld.so is to give higher priority to
> /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> libc6:amd64 in version 2.24 (using force-all), while keeping
> libc6-amd64:i386 in version 2.25.
> 
> The only way to change the priority of the two path is using a
> non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> this directory.
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
containing:

# Legacy biarch compatibility support
/lib64
/usr/lib64

and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:

# Legacy biarch compatibility support
/lib32
/usr/lib32

These files are created by the packages libc6-i386:x32 and 
libc6-amd64:x32. They cause that /lib64 is preferred to 
/lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
linker will prefer /lib/x86_64-linux-gnu/.

Mikulas

Bug#882264: Pending fixes for bugs in the libtemplate-declare-perl package

[pkg-perl-maintainers]

tag 882264 + pending
thanks

Some bugs in the libtemplate-declare-perl package are closed in
revision f51e1dfdbcf6e6bcd57e6aaddc6e0b7467779445 in branch 'master'
by gregor herrmann

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

Commit message:

Add a patch to fix test failures with HTML::Lint 2.26.

Closes: #882264

Bug#872251: libvoikko-dev is wrongly marked Multi-Arch: foreign

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi again,

2017-11-20 20:49 Helmut Grohne:

On Mon, Nov 20, 2017 at 01:23:07AM +0100, Manuel A. Fernandez Montecelo wrote:

 
https://anonscm.debian.org/cgit/collab-maint/libvoikko.git/commit/?id=94e7ce125739e59241c04034f5b0615e93c3cc49

Please review.  Explanations follow.


I don't think that this split makes sense as is.

Either you mark the new package M-A:foreign or you shouldn't split. If
some other package needs those tools, it certainly wants to execute
them. Thus it will need the build architecture version. In
build-depends, this can be achieved by annotating with :native or by
marking the package M-A:foreign (and the latter is wrong here). Thus
rdeps will have to put up with :native and that means you can simply
keep them together.

So marking the new package M-A:foreign may be an option. I'm not sure
whether it is correct. To figure out, someone should check whether the
tools *behave* the same on different architectures. If you feed them the
same input (input files, command line flags, environment, etc.), will
they have the same output? If the answer is "always yes", then
M-A:foreign is appropriate.

If M-A:foreign ends up being wrong, I'd not split at all, but simply
mark the -dev package M-A:no and update the relevant rdeps to use
:native.


So I think that this is what we're going to do now as the safest route,
I plan to NMU with this change.



If M-A:foreign ends up being correct, libvoikko-dev should actually
depend on the new package. Thus the full interface formerly provided by
libvoikko-dev keeps being provided by virtue of the dependency. But the
M-A headers will ensure that the library is for the host architecture
and the tools are for the build architecture. Consequently, I'd name the
package "libvoikko-dev-bin" and describe it as an implementation detail
of libvoikko-dev that you shouldn't use directly.


I think that it's worth trying that as it's a better solution, but it
needs understanding from the maintainer or someone who really groks the
tools and knows how the reverse-depends use them.

I reported another bug #882273 for that purpose.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#855876: Pending fixes for bugs in the etcd package

[pkg-go-maintainers]

tag 855876 + pending
thanks

Some bugs in the etcd package are closed in revision
0afc17c8a5f3ebbc6387a7223ae8192f8e3bd626 in branch 'master' by Dr.
Tobias Quathamer

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/etcd.git/commit/?id=0afc17c

Commit message:

Exclude the sockets from the MD5 sum generation.

Closes: #855876

Bug#882244: zstd: add zstd package to jessie-backports

[Andreas Tille]

Control: tags -1 pending

On Mon, Nov 20, 2017 at 11:51:28AM -0500, David Magda wrote:
> Package: zstd
> Severity: wishlist
> 
> It would be really handy to have a backports package available for
> Debian 8 so that zstd could be used for current systems without having
> to develope an in-house package.

Describing systems running Debian 8 as "current systems" is not really
what I would consider a correct description.  However, I uploaded to
Backports-new.  You need to wait until this is accepted.

> Thanks for your time.

You are welcome

 Andreas. 

-- 
http://fam-tille.de

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-20 19:13, Mikulas Patocka wrote:
> Package: libc6-amd64
> Version: 2.25-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I have a x86-64 system with i386 and x32 foreign architectures (because I
> need to develop software for i386 and x32 architectures).
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> 
>* What was the outcome of this action?
> 
> Halfway through apt upgrade it failed and I ended up with unusable system 
> where
> large number of binaries were segfauting on startup without doign anything.
> 
>* What outcome did you expect instead?
> 
> The upgrade to libc-2.25 should work.
> 
> 
> The reason for the catastrophic failure is this:
> 
> There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide

I guess you mean you have installed one of the two, not both.

> x86-64 libc in /lib64/). This package is not technically needed (because
> x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> installed nonetheless because of some dependencies.

Just to be clear, as said in my other email, this *is* technically
needed as gcc-multilib is not able to make use of the libc in
/lib/x86_64-linux-gnu.

> apt makes sure that all libc packages are upgraded at once to the same
> version. However, during the upgrade process, the package
> libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> temporarily have two libcs with different versions on the system, and this
> mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> upgrade doesn't proceed and it doesn't install the correct libc version in
> /lib/x86_64-linux-gnu/.
> 
> The result is unusable system.

I have done some tests, and while I confirm that libc6-i386:amd64 is
unpacked much before libc6:amd64, it doesn't cause any issue here.
Indeed the search path in ld.so is to give higher priority to
/lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
libc6:amd64 in version 2.24 (using force-all), while keeping
libc6-amd64:i386 in version 2.25.

The only way to change the priority of the two path is using a
non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
/etc/ld.so.conf.d/*? Maybe you can share the content of this file and
this directory.

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

Bug#882273: libvoikko: Please consider splitting the binaries from the -dev package and annotate resulting packages correctly with Multi-Arch

[Manuel A. Fernandez Montecelo]

Source: libvoikko
Version: 4.1.1-1
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap


Hello,

Stemming from #872251, these are the findings that we explained there and in IRC
discussions, I will try to summarise it as best as I can (corrections welcome):

- The binaries in the -dev package are not purely "test programs" or examples,
  because they are used by different packages [1] [2]

  + It is unfortunate that they are bundled together, because they make some
cases of co-installation with multi-arch or cross-compilation more difficult
or less correct, they preclude some combinations and uses

  + The annotation of "Multi-Arch: foreign" is simply wrong and it causes
problems to cross-compile, so better than this would even be to be marked as
(implicit, by removing the line) "Multi-Arch: no" as it is proposed for
#872251

  + Transitions to split the package while preserving the rev-depends or
previous systems with this package installed unbroken through upgrades are
more complicated now, read on

- It seems that the binaries can be split in a new -bin and be marked as
  "Multi-Arch: foreign", because the spell/grammar checkers and the rest of the
  tools should have the same behaviour, e.g. output the same content for the
  same input, independent of the architecture, but I'm/we're not 100% sure.

  + In that case, -dev should be "Multi-Arch: same" and -bin "Multi-Arch:
foreign", and -dev should Depend on -bin (to not break reverse-dependencies,
although many will not actually need those binaries), while -bin should
include Breaks/Replaces on older versions of -dev (because it takes over
some files)

For reference, the following commit (later reverted) attempted to do what's
needed, except that I failed to reach the correct solution for not marking
-bin as "Multi-Arch: foreign" and using Recommends instead of Depends (which
can cause upgradability problems, or satisfiability problems when building
in buildd):

  
https://anonscm.debian.org/cgit/collab-maint/libvoikko.git/commit/?id=94e7ce125739e59241c04034f5b0615e93c3cc49

  + If they do not behave the same way across architectures, the package can be
marked as "Multi-Arch: no" and the few reverse-deps can change the
dependency to use :native, but this is better known to the maintainer, and
you're also the maintainer of voikko-fi so you can easily change them in
lock-step.


Hope that helps, and that it's clear what to do once you know the tools and what
they're supposed to do and how they are used.

If you have any questions just ask, we'll try to help.


Cheers.


[1] https://codesearch.debian.net/search?q=voikkospell=1
giella-core_0.1.1~r129227+svn121148-1/scripts/run_voikko_speller.sh

[2] https://codesearch.debian.net/search?q=voikkovfstc=1
voikko-fi_2.2-1/Makefile


Cheers.

Bug#880941: pink-pony: diff for NMU version 1.4.1-2.1

[Adrian Bunk]

On Mon, Nov 20, 2017 at 11:45:27PM +0200, Adrian Bunk wrote:
> Control: tags 880941 + patch
> Control: tags 880941 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for pink-pony (versioned as 1.4.1-2.1) and uploaded 
> it to DELAYED/5. Please feel free to tell me if I should cancel it.

Apologies, I messed up and forgot to add the DELAYED parameter
when uploading.  :-(

> cu
> Adrian

cu
Adrian

-- 

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

Bug#878107: src:pcre3: stack frame size detection is broken

[Adrian Bunk]

Control: severity -1 serious
Control: tags -1 -moreinfo
Control: found -1 2:8.35-3.3

On Tue, Oct 10, 2017 at 11:47:31AM +0100, Matthew Vernon wrote:
> severity 878107 important
> tags 878107 + upstream moreinfo
> quit
> Hi,
> 
> On 09/10/17 21:23, Ondřej Surý wrote:
> 
> > the system-wide pcre3 library stack frame size detection is broken as 
> > described in
> > https://bugs.exim.org/show_bug.cgi?id=2173
> 
> I note that upstream aren't proposing to address this.

Upstream says:
  PCRE1 (the 8.xx series) is very much in "maintenance only" mode. PCRE2 
  (the 10.xx series) has been out for nearly 3 years now, and its most 
  recent release, 10.30, no longer uses the stack for remembering 
  backtracking points.

That's fair enough, especially considering that a proper fix might be hard.

But it doesn't help existing software that cannot immediately be ported 
to PCRE2 (even more in stable releases).


Upstream also says:
  This was always somewhat dodgy code, and since it was released I have 
  discovered that all kinds of compiler variations can alter the answer 
  that you get. With hindsight, it should never have been released.

One real-world problem where this dodgy code does break has been found 
to affect real software, and the suggested patch that disables some
otherwise possible optimizations for one function is confirmed to
workaround this specific breakage.

This is a quite minimal workaround for this specific breakage.


MariaDB has now made the step of using a bundled copy of PCRE when at 
build time the system version of PCRE is found to have this problem.

That's a reasonable decision, but obviously lacks fixes from the Debian 
package and using it would increase the amount of work for PCRE security 
updates.


> > and that breaks at least ppc64el and s390x build causing segfaults in the 
> > test suite (+ autopkgtest).
> 
> It's not clear to me that this couldn't be addressed by increasing the
> stack ulimit for the build (hence my request for moreinfo on 876299).

Doesn't fix the MariaDB test, and wouldn't fix it for all users of PCRE.


> > The patch from Sergei @ MariaDB is quite simple at it should pose no risk 
> > applying it:
> 
> ...and presumably won't work with clang?

clang knows about noinline (and implements it properly),
and gives a warning for the noclone it doesn't know:

$ cat test.c
#include 

static void printit(void) __attribute__((noinline,noclone));

static void printit(void)
{
  printf("Hello, world!\n");
}

int main(void)
{
  printit();
  return 0;
}
$ clang -O2 -Wall test.c -o test && ./test
test.c:3:51: warning: unknown attribute 'noclone' ignored 
[-Wunknown-attributes]
static void printit(void) __attribute__((noinline,noclone));
  ^
1 warning generated.
Hello, world!
$ 


> Regards,
> 
> Matthew

cu
Adrian

-- 

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

Bug#882096: kdenlive: please ship the translations

[Pino Toscano]

In data sabato 18 novembre 2017 23:12:06 CET, Pino Toscano ha scritto:
> Source: kdenlive
> Version: 17.08.3-1
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> since KDE Applications 17.04, the translations of Frameworks-based
> applications are provided with the applications themselves, and not
> anymore as part of kde-l10n.  This caused in the past conflicts because
> we still ship kde-l10n 16.04, and thus with kdenlive translations
> (bugs #863722).
> 
> Earlier today, I uploaded kde-l10n 4:16.04.3-2 which drops few
> translations, including the kdenlive ones: hence, they can be shipped
> again as part of kdenlive.  Attached there is a patch for this, which
> makes use of pkg-kde-tools to generate the correct substvar variable
> for breaks/replaces.

A small correction: the kde-l10n version with the right fixes is
4:16.04.3-4, so rules must have:

+l10npkgs_firstversion_ok := 4:16.04.3-4~

The rest of the patch applies.

-- 
Pino Toscano

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

Bug#882261: Acknowledgement (rsyslog: imjournal doesn't work)

[Michael Biebl]

Control: found -1 8.30.0-1
Control: severity -1 serious
Control: tags -1 + patch
Control: forwarded -1 https://github.com/rsyslog/rsyslog/issues/1897

Am 20.11.2017 um 21:27 schrieb Goffredo Baroncelli:
> The bug report contains the version "8.30.0-2ghigo1", because this is the one 
> which I generated when I rebuild  the packages rsyslogd with the upstream 
> commit 4736e53d471ac45024333588fcdf5bce5f8c61b8 (which solve this issue).
> Sorry for the confusion.

No problem. Let's fix the version tracking and mark this bug as serious
so this broken version does not migrate to testing.

Thanks for your bug report.


Michael



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



signature.asc
Description: OpenPGP digital signature

Bug#873411: kdevelop: Please update to llvm-toolchain 4.0 or, better, 5.0

[Emilio Pozuelo Monfort]

Hi Pino,

On 20/11/17 20:27, Pino Toscano wrote:
> Control: severity -1 important
> 
> (see below why...)
> 
> In data lunedì 20 novembre 2017 20:05:20 CET, Emilio Pozuelo Monfort ha 
> scritto:
>> Control: severity -1 serious
>>
>> On Wed, 06 Sep 2017 21:34:47 +0200 Pino Toscano  wrote:
>>> Hi,
>>>
>>> In data domenica 27 agosto 2017 16:01:25 CEST, Sylvestre Ledru ha scritto:
 Source: kdevelop
 Severity: normal

 Hello,

 Currently, we have 6 versions of the llvm toolchain in the archive.
 I would like to move to 3 versions (4.0, 5.0 and snapshot, aka 6.0)

 Could you please update your package to use 4.0 (or, better, 5.0 which 
 will be released very 
 soon)?
>>>
>>> Sure, but only after the versions available build and work at least on
>>> all the release architectures.  So far, llvm 3.9 is still affected by
>>> #866354, since it did not build fine again since then -- this is
>>> holding kdevelop in unstable for more than 2 months, and I really would
>>> like to get it into testing.
>>>
>>> I see that each of the llvm sources has various bugs, FTBFSes, cmake
>>> issues, and so forth... as a suggestion from a bystander, what about
>>> focusing on at most 3 versions of llvm in the archive, instead of
>>> upload every version available (and then have to cleanup llvm users
>>> periodically, like with bugs like this)?
>>>
 I will update the severity of this bug at the end of September
>>>
>>> Doing that with the current state of llvm versions would be a bad idea.
>>
>> It should be fine now with 4.0. Would be good if this could move to either
>> unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. 
>> Bumping
>> to serious as we want to remove 3.8 soon to reduce the high number of llvm
>> versions that we currently ship.
> 
> IMHO, if the goal would really be getting rid of old llvm versions in
> the archive, then (as I wrote above) the llvm maintainers ought to
> a) fix the latest stable (= 5.0)
> b) switch llvm-defaults to the above

I expect that will happen in due time. I see there's a 5.0.1 rc release in
experimental already, which is in a much better shape than the package in
unstable. Hopefully when 5.0.1 final is released it can go in unstable and the
remaining issues can be worked out.

In the meantime, that shouldn't block kdevelop from going back to unversioned
llvm, which defaults to 4.0 now, and when it gets bumped to 5.0, a binNMU will
be scheduled and you won't have to worry about it.

FWIW wrt your old comments: I would have no objections to uploading only every
other major release to Debian, but I am not an LLVM maintainer, and so long as
older releases get cleaned up and transitions are taken care of, I won't object.
We were due a llvm-defaults update, which just happened. Hopefully the process
is better understood now and an update for 5.0 or 6.0 won't take too long. Also
hopefully more packages go back to using the metapackages, so that we can just
scheduled binNMUs when the defaults are updated and be done with it. OTOH there
are very few rdeps so this is not a huge deal.

> llvm got versioned symbols, so loading two llvm versions in the same
> process (hello, mesa), although it is ugly. This should allow kdevelop
> to switch back to llvm-defaults, even if llvm maintainers should care
> a bit more about it, instead of almost letting it rot...

So you are saying that you can use llvm 4.0 even if mesa is using 5.0? That's 
good.

> Anyway, I just lowered the severity of this bug to important, so
> kdevelop 5.2 can migrate to testing.  Yes, it is an important update
> (merged kdevplatform, so the separate source can be dropped), so I
> really it to reach testing.
> Because of another issue in the past, related to llvm (#866354),
> kdevelop 5.1.x was stuck in unstable for basically 2 months. I don't
> want llvm to get in the way of kdevelop, once again.

I don't want that at all, so that's alright. I don't think this bug being
serious would have prevented kdevelop from migrating to testing anyway, as it's
not a 'regression'. In any case, I just noticed you're on llvm 3.9 and not 3.8,
and we can't remove 3.9 yet due to GHC (sigh), so this is less urgent. It'd
still be nice for this to move to unversioned llvm or to a newer one whenever
possible.

Hopefully that makes sense. Let me know if that's not the case.

Cheers,
Emilio

Bug#882271: libgradle-core-java: fail to honor maven relocations

[Emmanuel Bourg]

Le 20/11/2017 à 22:24, Gilles Filippini a écrit :

> As I understand it, gradle should follow the relocation and look for
>  
> file:/usr/share/maven-repo/com/github/cliftonlabs/json-simple/debian/json-simple-debian.jar
> instead of
>  
> file:/usr/share/maven-repo/com/googlecode/json-simple/json-simple/debian/json-simple-debian.jar

AFAIK this is a Gradle limitation. I don't know if more recent versions
support relocations.

Emmanuel Bourg

Bug#882245: systemd-sysv: shutdown does not parse correctly -t option

[Thomas L]

Hi Michael,

I can reproduce this bug on Strech as well (systemd-sysv 232-25+deb9u1).

I think you should however also fix this bug on Jessie, because it is a recent 
regression (was not present on Jessie 8.6). Based on the package's recent 
changelog, it may be a regression of "systemctl: Fix argument handling when 
invoked as shutdown. (Closes: #776997)" introduced on 215-17+deb8u6 (it's just 
a guess, but it is the only recent fix on shutdown's argument handling).

Regards
Thomas

Bug#881368: fis-gtm: please switch build-dep from libconfig8-dev to libconfig-dev

[Andreas Tille]

Hi Mattia,

On Fri, Nov 10, 2017 at 09:09:16PM +0100, Mattia Rizzolo wrote:
> Version: 6.3-002-3
> Severity: serious
> 
> I'm about to upload a libconfig dropping this transitional package,
> please update fis-gtm.

Fis-gtm Build-Depends: libconfig-dev | libconfig8-dev.

In how far is it serious to drop the second alternative?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#882093:

[Jeffrey Cliff]

this bug may be closed - looks like what I was requesting is called
node-json5 in debian, ie it's already here.

Bug#880941: pink-pony: diff for NMU version 1.4.1-2.1

[Adrian Bunk]

Control: tags 880941 + patch
Control: tags 880941 + pending

Dear maintainer,

I've prepared an NMU for pink-pony (versioned as 1.4.1-2.1) and uploaded 
it to DELAYED/5. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru pink-pony-1.4.1/debian/changelog pink-pony-1.4.1/debian/changelog
--- pink-pony-1.4.1/debian/changelog	2016-06-27 00:55:50.0 +0300
+++ pink-pony-1.4.1/debian/changelog	2017-11-20 23:39:25.0 +0200
@@ -1,3 +1,13 @@
+pink-pony (1.4.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove no longer required build dependency on glee-dev.
+(Closes: #880941)
+  * Stop using a non-default compressor
+(xz is now default, and it compresses better than bzip2).
+
+ -- Adrian Bunk   Mon, 20 Nov 2017 23:39:25 +0200
+
 pink-pony (1.4.1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru pink-pony-1.4.1/debian/control pink-pony-1.4.1/debian/control
--- pink-pony-1.4.1/debian/control	2016-06-27 00:55:50.0 +0300
+++ pink-pony-1.4.1/debian/control	2017-11-20 23:39:20.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Debian Games Team 
 Uploaders: Miriam Ruiz 
 Build-Depends: debhelper (>= 9), quilt, scons, pkg-config, dh-buildinfo,
- mesa-common-dev, libglu1-mesa-dev, libglfw3-dev, libxrandr-dev, glee-dev,
+ mesa-common-dev, libglu1-mesa-dev, libglfw3-dev, libxrandr-dev,
  libilmbase-dev, libdevil-dev, libftgl-dev, libsigc++-2.0-dev,
  libprotobuf-dev (>= 2), protobuf-compiler (>= 2), libtinyxml-dev,
  libsdl1.2-dev, libsdl-mixer1.2-dev
diff -Nru pink-pony-1.4.1/debian/source/options pink-pony-1.4.1/debian/source/options
--- pink-pony-1.4.1/debian/source/options	2016-06-24 12:28:46.0 +0300
+++ pink-pony-1.4.1/debian/source/options	2017-11-20 23:39:25.0 +0200
@@ -1,5 +1,2 @@
-# Bzip2 compression for debian.tar
-compression = "bzip2"
-compression-level = 7
 # Do not generate diff for changes in config.(sub|guess)
 extend-diff-ignore = "(^|/)config.(sub|guess)$"

Bug#882181: mockito: FTBFS - java.lang.UnsupportedOperationException: Cannot nest operations in the same thread

[Gilles Filippini]

Hi Markus,

Markus Koschany a écrit le 20/11/2017 à 21:17 :
> Control: tags -1 confirmed
> 
> Am 20.11.2017 um 00:27 schrieb Gilles Filippini:
>> Source: mockito
>> Version: 1.10.19-2
>> Severity: serious
>> Justification: FTBFS
>>
>> Hi,
>>
>> While testing a build of mockito against a new json-simple releae I've
>> experienced a FTBFS which is reproducible when building into a clean sid
>> chroot:
>>
>> Task :test class loader hash: 83f3637f6805a7b149525a93c5faad58
>> Task :test actions class loader hash: d883a18cf154fc57e90f4d3fa9e5588f
>> Executing task ':test' (up-to-date check took 0.041 secs) due to:
>>   No history is available.
>> Cannot nest operations in the same thread. Each nested operation must run in 
>> its own thread.
> 
> [...]
> 
> Hi,
> 
> thanks for reporting. This appears to be the same issue Olivier Sallou
> has mentioned on debian-java a few weeks ago. [1] This is a Gradle bug.
> I'm not exactly sure why it is surfacing now. I am in the process of
> updating Gradle to a newer version but it will take more time to finish
> the work.

I've just submitted another bug [1] against libgradle-core-java related
to the way it handles maven relocations.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882271

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-20 21:58, Mikulas Patocka wrote:
> 
> 
> On Mon, 20 Nov 2017, Samuel Thibault wrote:
> 
> > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > installed nonetheless because of some dependencies.
> > 
> > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> > tried to do it in the past, just to see, with the same kind of effect as
> > you had.
> > 
> > The question is rather how that got pulled at all. What package thinks
> > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > (which should normally not get pulled either), I can see uc-echo which
> > should rather use foreign dependencies, and :i386 multilib packages
> > which don't really make sense to install either.
> > 
> > I don't remember whether it was tried to make libc6-amd64:i386 conflict
> > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > doesn't happen by misfortune?
> > 
> > Samuel
> 
> libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
> lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, 
> lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> 
> If you install gcc-7-multilib for non-default architecture (i386 or x32), 
> it will inevitably pull libc6-amd64.

What's the point of doing that, as opposed for example building with
-m32 or mx32?

> If we removed libc6-amd64 at all, it would cause problems building amd64 
> packages on i386 system. We could make those lib64* packages dependent on 
> libc6:amd64 instead, but that would break if the user has i386 
> installation and he doesn't have amd64 foreign architecture set up.
> 
> It would be best to set it up so that libc6-amd64 doesn't install any 
> files only if libc6:amd64 is present. Could it be done with the deb 
> format?

It's not something possible, and it's even more complicated than that.
The current ugly way the multiarch + multilib is done, uses a different
libc for linking and executing. So you definitely need to install both
if you want to be able to build and execute code.

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

Bug#870635: mutt package is not using the official mutt tarball

[Antonio Radici]

Can I please ask both of you to stop this flame?

It's not helping anyone.

I'm currently the maintainer of the mutt package and I have made my commitment
to Kevin in multiple occasions to fix the current situation and I'm going to fix
it.

I've collaborated with Kevin in the past and he has always been very
collaborative, the same applies to the Richard from the neomutt community; the
relationship between the two hasn't been great but at the same time it is
legitimate to ask to package mutt as the mutt tarball and I'm going to honor
that commitment that I took in the past.

Please refrain from engaging in flames, it's just a waste of time and it's not
going to change the current situation or convince me to take a different avenue.

On Mon, Nov 20, 2017 at 01:18:26PM -0800, Kevin J. McCarthy wrote:
> On Mon, Nov 20, 2017 at 06:59:16PM +, Jonathan Dowland wrote:
> > On Mon, Nov 20, 2017 at 10:35:52AM -0800, Kevin J. McCarthy wrote:
[...]

Bug#882272: libc6:amd64: upgrade of libc6:amd64 + libc6:i386 + libc6-i686 breaks system

[Stepan Golosunov]

Package: libc6
Version: 2.24-11+deb9u1
Severity: critical
Justification: breaks the whole system


Upgrade of glibc packages from jessie to stretch versions failed
resulting in most programs (presumably all non-static 32-bit ones) to
segfault on start. I believe the following happend:
1. libc6:i386 and libc6:amd64 2.24-11+deb9u1 were unpacked,
/etc/ld.so.nohwcap was created by preinst scripts.
2. postinst of libc6:amd64 started running and removed
/etc/ld.so.nohwcap (as $hwcappkgs is empty for amd64).
3. As libc6-i686 2.19-18+deb8u10 was still installed most applications
started segfaulting (including most essential ones).

Unfortunately, I did not have any root shell open, and while
export LD_HWCAP_MASK=0
workaround worked on many applications, it had no effect on setuid
programs (like su and sudo). I had to resolve the problem by rebooting
system with break=init argument and running
touch /root/etc/ld.so.nohwcap
from initramfs shell (and later calling
dpkg --purge libc6-i686
before finishing upgrade of libc6:amd64).

This probably should be fixed by replacing

case ${DPKG_MAINTSCRIPT_ARCH} in
alpha)
hwcappkgs="libc6-alphaev67"
;;
i386)
hwcappkgs="libc6-i686 libc6-xen"
;;
kfreebsd-i386)
hwcappkgs="libc0.1-i686"
;;
esac

with something like

hwcappkgs="libc6-alphaev67 libc6-i686 libc6-xen libc0.1-i686"

or

hwcappkgs="libc6.1-alphaev67:alpha libc6-i686:i386 libc6-xen:i386 
libc0.1-i686:kfreebsd-i386"

in debian/script.in/nohwcap.sh.


sghpc% sudo apt upgrade
Чтение списков пакетов… Готово
Построение дерева зависимостей   
Чтение информации о состоянии… Готово
Расчёт обновлений…Следующие пакеты устанавливались автоматически и больше не 
требуются:
  aumix aumix-common bzip2-doc gdb-doc libc6-i686 
linux-image-3.16.0-4-amd64:amd64 linux-image-4.9.0-3-amd64-dbg:amd64
  python-networkx python-pygraphviz python-skimage python-skimage-lib
Для их удаления используйте «apt-get autoremove».
Готово
НОВЫЕ пакеты, которые будут установлены:
  libc-l10n
Пакеты, которые будут оставлены в неизменном виде:
  geeqie geeqie-common geeqie-dbg
Пакеты, которые будут обновлены:
  glibc-doc libc-bin libc-dev-bin libc6 libc6:amd64 libc6-dbg libc6-dbg:amd64 
libc6-dev libc6-i686 locales locales-all
  multiarch-support
обновлено 12, установлено 1 новых пакетов, для удаления отмечено 0 пакетов, и 3 
пакетов не обновлено.
Необходимо скачать 0 B/44,6 MB архивов.
После данной операции, объём занятого дискового пространства уменьшится на 9 
642 kB.
Хотите продолжить? [Д/н] 
Чтение журнала изменений... Выполнено 
apt-listchanges: Хотите продолжить? [Y/n] 
apt-listchanges: Отправка почты root: apt-listchanges: журнал изменений sghpc
apt-listchanges: Отправка почты root: apt-listchanges: новости о sghpc
Предварительная настройка пакетов ...
(Чтение базы данных … на данный момент установлено 803482 файла и каталога.)
Подготовка к распаковке …/locales_2.24-11+deb9u1_all.deb …
Распаковывается locales (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Выбор ранее не выбранного пакета libc-l10n.
Подготовка к распаковке …/libc-l10n_2.24-11+deb9u1_all.deb …
Распаковывается libc-l10n (2.24-11+deb9u1) …
Подготовка к распаковке …/locales-all_2.24-11+deb9u1_i386.deb …
Распаковывается locales-all (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Подготовка к распаковке …/libc6_2.24-11+deb9u1_i386.deb …
Деконфигурируется libc6:amd64 (2.19-18+deb8u10) …
Checking for services that may need to be restarted...
Checking init 
scripts...##.]
 
Распаковывается libc6:i386 (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Подготовка к распаковке …/libc6_2.24-11+deb9u1_amd64.deb 
….] 
Checking for services that may need to be 
restarted]
 
Checking init scripts...
Распаковывается libc6:amd64 (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Настраивается пакет libc6:amd64 (2.24-11+deb9u1) 
….] 
dpkg: ошибка при обработке пакета libc6:amd64 
(--configure):...] 
 подпроцесс установлен сценарий post-installation уничтожен по сигналу (Ошибка 
сегментирования)
Настраивается пакет libc6:i386 (2.24-11+deb9u1) …
Устанавливается новая версия файла настройки 
/etc/ld.so.conf.d/i386-linux-gnu.conf …
dpkg: ошибка при обработке пакета libc6:i386 
(--configure):] 
 подпроцесс установлен сценарий post-installation уничтожен по сигналу (Ошибка 
сегментирования)
При обработке следующих пакетов произошли ошибки:
 libc6:amd64
 libc6:i386
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Problem executing scripts DPkg::Post-Invoke 

Bug#882271: libgradle-core-java: fail to honor maven relocations

[Gilles Filippini]

Package: libgradle-core-java
Version: 3.2.1-5
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

While testing a build of mockito against a new json-simple releae I've
experienced a FTBFS due - IIUC - to gradle failing to honor correctly
a maven relocation:

...
Generating gradleApi JAR file: 
/<>/.gradle/caches/3.2.1/generated-gradle-jars/gradle-api-3.2.1.jar
Generating JAR file 'gradle-api-3.2.1.jar'
Keep-alive timer started
Adding Debian repository to project 'buildSrc'
Parallel execution is an incubating feature.
Evaluating root project 'buildSrc' using build file 
'/<>/buildSrc/build.gradle'.
Compiling build file '/<>/buildSrc/build.gradle' using 
SubsetScriptTransformer.
Compiling build file '/<>/buildSrc/build.gradle' using 
BuildScriptTransformer.
Adding task debianMavenPom to project 'buildSrc'
Configuring javadoc links
Replacing com.googlecode.json-simple:json-simple:jar:1.1.1  ->  
com.googlecode.json-simple:json-simple:jar:debian
com.googlecode.json-simple:json-simple:debian is relocated to 
com.github.cliftonlabs:json-simple:debian. Please update your dependencies.
Stopped 0 compiler daemon(s).

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration ':runtime'.
> Could not find json-simple.jar 
> (com.googlecode.json-simple:json-simple:debian).
  Searched in the following locations:
  
file:/usr/share/maven-repo/com/googlecode/json-simple/json-simple/debian/json-simple-debian.jar

* Try:
Run with --debug option to get more log output.

* Exception is:
org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies 
for configuration ':runtime'.
at 
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.wrapException(ErrorHandlingConfigurationResolver.java:70)
at 
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.access$000(ErrorHandlingConfigurationResolver.java:33)
at 
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingConfigurationResolver.java:208)
 
...


As I understand it, gradle should follow the relocation and look for
 
file:/usr/share/maven-repo/com/github/cliftonlabs/json-simple/debian/json-simple-debian.jar
instead of
 
file:/usr/share/maven-repo/com/googlecode/json-simple/json-simple/debian/json-simple-debian.jar

This bug is easily reproducible building mockito againt json-simple 
2.3.0-1~exp1 currently in experimental.

Thanks,

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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAloTR/4ACgkQ7+hsbH/+
z4M/Tgf8CTl/EtClc2skjCpQA78YKnpTDcxq4EFYC/SJ00Pq94+AxbtaAwKNcbQ5
LlyC8O42LJfbh3yd92yzaZRi3D9rKutslDCsyfQlVeyD61ukwRPeu42xY9muekl9
RoDKSRN35PgeN6O+wlqFfFH4EdbFkVzf4pDXBzA7eSbTcp2rmAeq8nJ1091hOT/M
DXwj6LZrgl9mqOtA9EOJpOkimL/qzyUZwBu4OvtlrFTtNg5gXXhj7ckkLR4vXlAX
zMnyTbJC+R2WufXSBKLjGQpHk8FJCgzT2QnTduP0uGm2Z2xMe0Ud/Mi97CTAjeMV
o2U/SLXRWWxGb1JOJekzgMU1doIHFQ==
=ZMiE
-END PGP SIGNATURE-

Bug#870635: mutt package is not using the official mutt tarball

[Kevin J. McCarthy]

On Mon, Nov 20, 2017 at 06:59:16PM +, Jonathan Dowland wrote:
> On Mon, Nov 20, 2017 at 10:35:52AM -0800, Kevin J. McCarthy wrote:
> > Yes, I can understand the desire to sweep the whole mess under the rug.
> 
> That's not what I am proposing at all. I'm suggesting we put our users
> first, and on balance, I think switching neomutt users to mutt would not
> be the best outcome.

And how dare I be hostile, since your opinion seems to be without any
knowledge of what has happened, or of the work that has taken place in
Mutt the last few years under my development.

Incidentally, my comment was intended to be in reference to:

> (The wisdom of having moved the package *to* neomutt at this point is
> irrelevant, because it has happened whether we like it or not.)

> That would only address testing/unstable and future Debian releases, and
> not current stable, although I'm not sure yet what we can do about that
> within the confines of our normal rules and processes.

Yes, I'm aware of the situation of stable.  Antonio has clearly kept me
informed that stable is not possible to remedy.

> It would also be unethical to upload software that we had no intention
> of ever actually supporting properly.

Oh, now Debian is concerned about what is ethical?  If no one cares
about the mutt package, then let it die.  Or let another developer pick
up the package.  But allow that possibility now, not in 3 years after
another release cycle using a transition package.

> Finally it would switch all existing users from one software to another
> unexpectedly: just because we did that once doesn't mean we should do it
> again.

I believe this is an example of false equivalence.  Is unexpectedly
switching *mutt* package users to NeoMutt the same as switching them
back to Mutt?

This is also part of the "sweep the whole mess under the rug" argument
you are perpetuating: "Oh well, we did it.  Can't do anything about it,
can't go back... gosh there's just nothing to do but turn mutt into a
transition package."

> > Since Debian has basically taken away all my work
> 
> No we haven't. Please try harder to engage with us in a constructive and
> less hostile manner, and stop assuming bad faith. We are only having
> this conversation at all for your sake.

Spare me.  We are having this conversation because Debian is violating
my copyright, and I filed an RC bug.  Debian behaved unethically,
reprehensibly, and with extreme disrespect towards me and the Mutt
project.

And, yes, Debian _has_ taken away all my work since 1.6.x, when they
started applying massive patches from the NeoMutt project to my
releases.  I already laid out my viewpoint in this thread:
https://marc.info/?l=mutt-users=149880626013418=2

This occurred *after* I particularly tried to engage with the Debian
maintainers, triage, and start fixing bugs out of their ticket system.
If you really care, have a talk with them - I emailed them about this
just after that release.  A lot of good that did.

> You've come as close as you've managed at pitching to us we actually
> package mutt here.

> Given that, I'm surprised you've been so hostile. Do you expect to bully
> us into doing what you want? Please do bear in mind that another
> important consideration for packaging something is a healthy
> relationship with upstream.

Please stop speaking as if you are one of the mutt package maintainers.
I don't need to make a pitch to you, and I don't give a toot about a
"healthy relationship" at this point.

The mutt package maintainers made their choice, and ruined the
relationship all on their own.  They had many opportunities to fix it
over the past few releases, but instead doubled and tripled-down,
culminating in the complete tarball swapout.

That needs to be fixed.  I would prefer it not be in a way that removes
Mutt from Debian, but at this point I'm not going to make pitches or
temper my well-justified hostility.

-Kevin


signature.asc
Description: PGP signature

Bug#877776: live-boot: fixed read-only mode with overlayfs

[Raphael Hertzog]

Hello Ronny,

On Thu, 05 Oct 2017, Ronny Standtke wrote:
> Read-only persistence mode doesn't currently work with overlayfs. The
> attached patch fixes this issue.

Can you be a bit more verbose in your explanation?

How can we reproduce the problem?

Why is your patch fixing the issue?

I will gladly commit your patch but I have to understand the problem
and understand how your patch is fixing it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Mon, 20 Nov 2017, Samuel Thibault wrote:

> Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> tried to do it in the past, just to see, with the same kind of effect as
> you had.
> 
> The question is rather how that got pulled at all. What package thinks
> it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> (which should normally not get pulled either), I can see uc-echo which
> should rather use foreign dependencies, and :i386 multilib packages
> which don't really make sense to install either.
> 
> I don't remember whether it was tried to make libc6-amd64:i386 conflict
> with libc6:amd64 (and vice-versa for i386) to make sure that this
> doesn't happen by misfortune?
> 
> Samuel

libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, 
lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.

If you install gcc-7-multilib for non-default architecture (i386 or x32), 
it will inevitably pull libc6-amd64.

If we removed libc6-amd64 at all, it would cause problems building amd64 
packages on i386 system. We could make those lib64* packages dependent on 
libc6:amd64 instead, but that would break if the user has i386 
installation and he doesn't have amd64 foreign architecture set up.

It would be best to set it up so that libc6-amd64 doesn't install any 
files only if libc6:amd64 is present. Could it be done with the deb 
format?

Mikulas

Bug#769761: mercurial: does not support SNI on for https: URLs

[Steven Chamberlain]

Hi,

Upstream's patch works with mercurial/3.1.2-2+deb8u4 in oldstable:
https://www.mercurial-scm.org/repo/hg/rev/bf07c19b4c82

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#881110: cacti: CVE-2017-16641: arbitrary execution of os commands via path_rrdtool parameter in an action=save request

[Paul Gevers]

Hi Salvatore,

On 20-11-17 21:30, Salvatore Bonaccorso wrote:
> Sorry for the delayed reply.

NP.

> Ok! Your arguing makes sense to me, and I went ahead to mark the
> issue as no-dsa for stretch and jessie.

Thanks.

> Still if upstream provides
> help in adressing any of those two issues would be great to se fixes
> at some point e.g. via a point release or picked up in a DSA as well.

Sure, will do. I am hoping that upstream will provide a patch for
CVE-2009-4112 in a reasonable time from now. Upstream has really stepped
up since the preparation of 1.x started and they were getting closer to
actually releasing it. If/once that happens, I'll make sure I'll
backport both that patch and the one for this issue, but then it is
worth the effort in my opinion.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#882270: systemd-logind crashes when closing lid after "systemctl mask sleep.target"

[Lars Stoltenow]

Package: systemd
Version: 235-3
Severity: normal

Dear Maintainer,

I want to be able to configure if my laptop should suspend when closing the
lid. Because I do not want to kill the X session for this, changing logind.conf
and restarting logind is not an option. Therefore, I set
HandleLidSwitch=suspend and HandleLidSwitchDocked=suspend and want to manually
disable suspend using "systemctl mask sleep.target suspend.target".

It works insofar that when closing the lid, the laptop doesn't suspend,
but logind crashes multiple times in rapid succession. journalctl:

Nov 20 21:39:26 litterbox systemd-logind[10697]: Lid closed.
Nov 20 21:39:26 litterbox systemd-logind[10697]: Suspending...
Nov 20 21:39:26 litterbox systemd-logind[10697]: Assertion 'signal_name[w]' 
failed at ../src/login/logind-dbus.c:1495, function send_prepare_for(). 
Aborting.
[...unrelated kernel log entries...]
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Main process 
exited, code=killed, status=6/ABRT
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Failed with 
result 'signal'.
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Service has no 
hold-off time, scheduling restart.
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Scheduled restart 
job, restart counter is at 2.
Nov 20 21:39:26 litterbox systemd[1]: Stopped Login Service.
Nov 20 21:39:26 litterbox systemd[1]: Starting Login Service...
Nov 20 21:39:26 litterbox systemd[1]: Started Login Service.
Nov 20 21:39:26 litterbox systemd-logind[10892]: New seat seat0.
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event6 (Power Button)
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event4 (Power Button)
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event3 (Lid Switch)
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event5 (Sleep Button)
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event1 (Logitech USB Receiver)
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event2 (Logitech USB Receiver)
Nov 20 21:39:26 litterbox systemd-logind[10892]: Watching system buttons on 
/dev/input/event0 (AT Translated Set 2 keyboard)
Nov 20 21:39:26 litterbox systemd-logind[10892]: New session 4 of user penma.
Nov 20 21:39:26 litterbox systemd-logind[10892]: New session 1 of user penma.
Nov 20 21:39:26 litterbox systemd-logind[10892]: Suspending...
Nov 20 21:39:26 litterbox systemd-logind[10892]: Assertion 'signal_name[w]' 
failed at ../src/login/logind-dbus.c:1495, function send_prepare_for(). 
Aborting.
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Main process 
exited, code=killed, status=6/ABRT
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Failed with 
result 'signal'.
Nov 20 21:39:26 litterbox systemd[1]: systemd-logind.service: Service has no 
hold-off time, scheduling restart.
[...continues multiple times until...]
Nov 20 21:39:27 litterbox systemd[1]: systemd-logind.service: Scheduled restart 
job, restart counter is at 7.
Nov 20 21:39:27 litterbox systemd[1]: Stopped Login Service.
Nov 20 21:39:27 litterbox systemd[1]: systemd-logind.service: Start request 
repeated too quickly.
Nov 20 21:39:27 litterbox systemd[1]: systemd-logind.service: Failed with 
result 'signal'.
Nov 20 21:39:27 litterbox systemd[1]: Failed to start Login Service.

after which the whole X session goes down because

[  1689.396] (EE)
Fatal server error:
[  1689.396] (EE) systemd-logind disappeared (stopped/restarted?)
[  1689.396] (EE)
[  1689.396] (EE)
Please consult the The X.Org Foundation support at http://wiki.x.org for help.

The crashes are reproducible when the events above are masked, and they
also reliably disappear after unmasking said events.

I feel that logind should not crash in this situation, even if there happens to
be a better way to prevent suspend from happening. (For what I'm trying to
achieve right now, "systemd-inhibit --what=handle-lid-switch cat" is good
enough and doesn't crash logind)

I run X via startx with no desktop environment (only dwm).


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b2
ii  libaudit1   1:2.4.5-1
ii  libblkid1   2.29-1
ii  libc6   2.24-7
ii  libcap2 1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.5-3
ii  libgpg-error0   1.21-1
ii  libidn111.33-1
ii  

Bug#882269: kde-l10n-de: Ohter application cause conflict with version old than 4:17.08.3-1

[Achim Schaefer]

Package: kde-l10n-de
Version: 4:17.08.3-1
Severity: normal

Dear Maintainer,

the versions older than 4:17.08.3-1 cause trouble while installing software 
from this kde version.
There should be a conflict against them, so this package gets installed first.

Thanks

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

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

Versions of packages kde-l10n-de depends on:
ii  libkdecore5  4:4.14.36-1
ii  libkf5i18n5  5.37.0-2

kde-l10n-de recommends no packages.

Versions of packages kde-l10n-de suggests:
ii  kde-standard  5:92

-- no debconf information

Bug#882249: Welcome to Amazon - congrats mary 6UyR

[mroberts1128 .]

Please stop sending me these emails

On Mon, Nov 20, 2017 at 11:14 AM, thank you  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang




-- 
Mary Roberts
409-351-9301

Bug#882268: networking-ovs-dpdk FTBFS: AttributeError: 'module' object has no attribute 'VIF_TYPE_VHOST_USER'

[Adrian Bunk]

Source: networking-ovs-dpdk
Version: 2015.1.1+git20151118.35ac4c7-1
Severity: serious

Some recent change in unstable makes networking-ovs-dpdk FTBFS:

https://tests.reproducible-builds.org/debian/history/networking-ovs-dpdk.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/networking-ovs-dpdk.html

...
==
FAIL: 
unittest2.loader._FailedTest.networking_ovs_dpdk.tests.unit.driver.test_mech_dpdk_ovs
unittest2.loader._FailedTest.networking_ovs_dpdk.tests.unit.driver.test_mech_dpdk_ovs
--
_StringException: Traceback (most recent call last):
ImportError: Failed to import test module: 
networking_ovs_dpdk.tests.unit.driver.test_mech_dpdk_ovs
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File "networking_ovs_dpdk/tests/unit/driver/test_mech_dpdk_ovs.py", line 27, 
in 
class OVSDPDKMechanismBaseTestCase(base.AgentMechanismBaseTestCase):
  File "networking_ovs_dpdk/tests/unit/driver/test_mech_dpdk_ovs.py", line 28, 
in OVSDPDKMechanismBaseTestCase
VIF_TYPE = portbindings.VIF_TYPE_VHOST_USER
AttributeError: 'module' object has no attribute 'VIF_TYPE_VHOST_USER'


--
Ran 1 test in 3.646s

FAILED (failures=1)
debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#882267: php-mockery FTBFS: Class 'DOMDocument' not found

[Adrian Bunk]

Source: php-mockery
Version: 0.9.5-1
Severity: serious
Tags: buster sid

Some recent change in unstable (PHP 7.1?) makes php-mockery FTBFS:

https://tests.reproducible-builds.org/debian/history/php-mockery.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/php-mockery.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/php-mockery-0.9.5'
phpunit --include-path library --bootstrap debian/bootstrap.php
Class 'DOMDocument' not found
debian/rules:18: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#881900: stretch-pu: package libofx/1:0.9.10-2+deb9u1

[Dylan Aïssi]

Hi Adam,

2017-11-19 23:38 GMT+01:00 Adam D. Barratt :
>
> Flagged for acceptance.
>

Thanks. I just opened a similar bug for libofx in Jessie (#882132).

Best,
Dylan

Bug#882266: horizon accesses the internet during the build

[Adrian Bunk]

Source: horizon
Version: 3:12.0.0-4
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/horizon.html

...
==
ERROR: Failure: ConnectionError 
(HTTPSConnectionPool(host='translate.openstack.org', port=443): Max retries 
exceeded with url: /rest/project/horizon/version/master/locales (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary 
failure in name resolution',)))
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 418, in 
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/build/1st/horizon-12.0.0/horizon/management/commands/pull_catalog.py", 
line 21, in 
ZANATA_LOCALES = requests.get("https://translate.openstack.org/rest/project;
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 72, in get
return request('get', url, params=params, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 58, in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 502, in 
request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 612, in 
send
r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 504, in 
send
raise ConnectionError(e, request=request)
ConnectionError: HTTPSConnectionPool(host='translate.openstack.org', port=443): 
Max retries exceeded with url: /rest/project/horizon/version/master/locales 
(Caused by NewConnectionError(': Failed to establish a new connection: [Errno -3] 
Temporary failure in name resolution',))

--
Ran 209 tests in 66.346s

FAILED (SKIP=7, errors=1)
...

Bug#882265: python-rsvg: Please provide python3-rsvg

[Torquil Macdonald Sørensen]

Package: python-rsvg
Version: 2.32.0+dfsg-4
Severity: wishlist

There doesn't seem to be a python3-rsvg package in Debian. It would be nice to 
have.

Best regards,
Torquil Sørensen

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

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

Versions of packages python-rsvg depends on:
ii  libatk1.0-0  2.26.1-1
ii  libc62.25-1
ii  libcairo21.15.8-2
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-0.1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.2-1
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.13-2
ii  libpangocairo-1.0-0  1.40.13-2
ii  libpangoft2-1.0-01.40.13-2
ii  librsvg2-2   2.40.18-2
ii  librsvg2-common  2.40.18-2
ii  python   2.7.14-1
pn  python-gtk2  

python-rsvg recommends no packages.

python-rsvg suggests no packages.

-- no debconf information

Bug#882264: libtemplate-declare-perl FTBFS with libhtml-lint-perl 2.26+dfsg-1

[Adrian Bunk]

Source: libtemplate-declare-perl
Version: 0.47-1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libtemplate-declare-perl.html

...
Test Summary Report
---
t/aliasing.t  (Wstat: 1280 Tests: 30 Failed: 5)
  Failed tests:  11, 16, 21, 26, 30
  Non-zero exit status: 5
t/arg-declaration-styles.t (Wstat: 2048 Tests: 39 Failed: 8)
  Failed tests:  3, 6, 9, 15, 21, 27, 33, 39
  Non-zero exit status: 8
t/attributes.t(Wstat: 1280 Tests: 10 Failed: 5)
  Failed tests:  2, 4, 6, 8, 10
  Non-zero exit status: 5
t/closures.t  (Wstat: 2048 Tests: 16 Failed: 8)
  Failed tests:  2, 4, 6, 8, 10, 12, 14, 16
  Non-zero exit status: 8
t/forms.t (Wstat: 256 Tests: 2 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
t/importing.t (Wstat: 512 Tests: 18 Failed: 2)
  Failed tests:  14, 18
  Non-zero exit status: 2
t/indexhtml.t (Wstat: 512 Tests: 4 Failed: 2)
  Failed tests:  2, 4
  Non-zero exit status: 2
t/mixing.t(Wstat: 1280 Tests: 30 Failed: 5)
  Failed tests:  11, 16, 21, 26, 30
  Non-zero exit status: 5
t/private.t   (Wstat: 1024 Tests: 14 Failed: 4)
  Failed tests:  3, 6, 9, 12
  Non-zero exit status: 4
t/self.t  (Wstat: 256 Tests: 3 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
t/siblings.t  (Wstat: 768 Tests: 7 Failed: 3)
  Failed tests:  2, 4, 7
  Non-zero exit status: 3
t/subclassing.t   (Wstat: 768 Tests: 11 Failed: 3)
  Failed tests:  3, 5, 11
  Non-zero exit status: 3
t/subtemplates.t  (Wstat: 1024 Tests: 9 Failed: 4)
  Failed tests:  2, 4, 6, 9
  Non-zero exit status: 4
t/trivial.t   (Wstat: 1024 Tests: 9 Failed: 4)
  Failed tests:  2, 4, 6, 9
  Non-zero exit status: 4
t/utf8.t  (Wstat: 1536 Tests: 12 Failed: 6)
  Failed tests:  2, 4, 6, 8, 10, 12
  Non-zero exit status: 6
t/xss.t   (Wstat: 1024 Tests: 8 Failed: 4)
  Failed tests:  2, 4, 6, 8
  Non-zero exit status: 4
Files=51, Tests=478, 12 wallclock secs ( 0.23 usr  0.15 sys +  6.65 cusr  0.71 
csys =  7.74 CPU)
Result: FAIL
Failed 16/51 test programs. 65/478 subtests failed.
Makefile:786: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 4

Bug#874295: clementine: installs non-free plugin at runtime

[Anthony DeRobertis]

(from Jonas Smedegaard  via the bug):

> One of several functions of Clementine is to stream audio from cloud
> service Spotify.  Initially selecting that function triggers a routine
> where Clementine (asks for concent and then) downloads and installs a
> non-free binary driver.
> 
> Policy 2.2.1 states that "None of the packages in the main archive area
> require software outside of that area to function."
> 
> Clementine should either be moved to contrib, or the Spotify function be
> removed.

I suggest this isn't a Policy violation. Clementine functions without
the Spotify plugin; e.g., it'll happily play local music files, or from
any of the non-Spotify streaming sources.

Compare to, for example, all web browsers except lynx (and similar).
They all happily and automatically download and execute non-free code
(JavaScript), without any warning whatsoever. And if you turn off
JavaScript, they lose quite a bit more functionality than Clementine
does (I'd go so far as to say they become fairly useless — quite a bit
of the web doesn't work w/o JavaScript).

Many of them have their own plugin services (at least both Firefox and
Chromium do) that happily install and execute non-free code, again
without any warning (the only warnings they give are about access to
data, browsing history, etc., nothing about freedom).

Further, Debian understands software broadly (including, e.g.,
data—basically, "not hardware"), not just executables. If this bug
report's reading of policy were correct, Clementine would need to
disable most of streaming music services as the music they provide
doesn't follow DFSG. (And even lynx would have to be removed.)

I think it'd be reasonable to make the confirmation dialog explicitly
say that the plugin is not free software. But other than that, which
does not warrant severity: serious, I think this bug should be closed as
not a bug.

Bug#882263: libc6-dev-mips64el-cross breaks linking executables

[Helmut Grohne]

Package: libc6-dev-mips64el-cross
Version: 20
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

I was trying to use gcc-mips64el-linux-gnuabi64 to link a trivial
executable:

$ echo 'int main(){return 0;}' | mips64el-linux-gnuabi64-gcc -x c - -o /dev/null

With libc6-dev:mips64el installed, this just works. As soon as I install
libc6-dev-mips64el-cross, it fails though:

/usr/lib/gcc-cross/mips64el-linux-gnuabi64/7/../../../../mips64el-linux-gnuabi64/bin/ld:
 cannot find /usr/mips64el-linux-gnuabi64/lib/ld.so.1
collect2: error: ld returned 1 exit status

This renders libc6-dev-mips64el-cross pretty much useless.

Helmut

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-20 20:47, Samuel Thibault wrote:
> Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> tried to do it in the past, just to see, with the same kind of effect as
> you had.
> 
> The question is rather how that got pulled at all. What package thinks
> it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> (which should normally not get pulled either), I can see uc-echo which
> should rather use foreign dependencies, and :i386 multilib packages
> which don't really make sense to install either.
> 
> I don't remember whether it was tried to make libc6-amd64:i386 conflict
> with libc6:amd64 (and vice-versa for i386) to make sure that this
> doesn't happen by misfortune?

Arch-qualified conflicts are not supported. What you can do is make
libc6-amd64 and libc6:amd64 not coinstallable (by changing the Replaces
into a Conflicts). Maybe it's time to do it and let GCC enjoy multiarch
+ multilib pain.

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

Bug#881110: cacti: CVE-2017-16641: arbitrary execution of os commands via path_rrdtool parameter in an action=save request

[Salvatore Bonaccorso]

Hi Paul,

Sorry for the delayed reply.

On Fri, Nov 10, 2017 at 09:26:17PM +0100, Paul Gevers wrote:
> Control: severity -1 important
> Control: tags -1 pending
> 
> Hi all,
> 
> On 07-11-17 22:17, Salvatore Bonaccorso wrote:
> > Severity: grave
> > CVE-2017-16641[0]:
> > | lib/rrd.php in Cacti 1.1.27 allows remote authenticated administrators
> > | to execute arbitrary OS commands via the path_rrdtool parameter in an
> > | action=save request to settings.php.
> 
> Although this is true, and this parameter is not meant to be used like
> this, the cacti *admin* has always had this possibility via the "Data
> Input Method" freedom, which caused CVE-2009-4112 / bug 561339 to be
> raised. I just confirmed that I could indeed still do the via that
> (trivial) route.
> 
> So just to be clear (and I don't particularly like it), the power of the
> cacti *admin* has been long known and has been accepted as unfixed for
> multiple Debian releases. Therefor I lower the severity of this bug.
> 
> Unfortunately the upstream patch for this bug does not simply apply to
> pre 1.x versions of cacti. I am not comfortable (yet) with creating a
> patch for those versions, and due to CVE-2009-4112, I don't think it is
> worth fixing this in stable and older.

Ok! Your arguing makes sense to me, and I went ahead to mark the
issue as no-dsa for stretch and jessie. Still if upstream provides
help in adressing any of those two issues would be great to se fixes
at some point e.g. via a point release or picked up in a DSA as well.

Regards,
Salvatore

Bug#882262: ITP: libppix-documentname-perl -- utility to extract a name from a PPI Document

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libppix-documentname-perl
  Version : 0.001003
  Upstream Author : Kent Fredric 
* URL : https://metacpan.org/release/PPIx-DocumentName
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : utility to extract a name from a PPI Document

PPIx::DocumentName contains a few utilities for extracting a "name" out of an
arbitrary Perl file.

Typically, this is the module name, in the form:

 package Foo

However, it also supports extraction of an override statement in the form:

 # PODNAME: OverrideName::Goes::Here

which may be more applicable for documents that lack a package statement, or
the package statement may be "wrong", but they still need the document parsed
under the guise of having a name (for purposes such as POD).

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#882261: Acknowledgement (rsyslog: imjournal doesn't work)

[Goffredo Baroncelli]

The bug report contains the version "8.30.0-2ghigo1", because this is the one 
which I generated when I rebuild  the packages rsyslogd with the upstream 
commit 4736e53d471ac45024333588fcdf5bce5f8c61b8 (which solve this issue).
Sorry for the confusion.

Bug#841144: kernel BUG at linux-4.7.5/fs/ocfs2/alloc.c:1514!

[John Lightsey]

tags 841144 + patch
thanks

I'm attaching the patch we used at cPanel to fix this issue with the
4.9 Debian Stable kernel.

I forwarded a version of this patch to the ocfs2-devel mailing list
already.

From  Mon Sep 17 00:00:00 2001
From: John Lightsey 
Date: Mon, 20 Nov 2017 13:55:05 -0600
Subject: [PATCH] Fix OCFS2 extent split estimation for dio allocators locking.

The dw_zero_count tracking was assuming that w_unwritten_list would
always contain one element. The actual count is now tracked whenever
the list is extended.
---
 fs/ocfs2/aops.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index f2961b1..18a311d 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -775,6 +775,8 @@ struct ocfs2_write_ctxt {
 	struct ocfs2_cached_dealloc_ctxt w_dealloc;
 
 	struct list_head		w_unwritten_list;
+
+	unsigned int			w_unwritten_count;
 };
 
 void ocfs2_unlock_and_free_pages(struct page **pages, int num_pages)
@@ -864,6 +866,7 @@ static int ocfs2_alloc_write_ctxt(struct ocfs2_write_ctxt **wcp,
 
 	ocfs2_init_dealloc_ctxt(>w_dealloc);
 	INIT_LIST_HEAD(>w_unwritten_list);
+	wc->w_unwritten_count = 0;
 
 	*wcp = wc;
 
@@ -1364,6 +1367,7 @@ static int ocfs2_unwritten_check(struct inode *inode,
 	desc->c_clear_unwritten = 0;
 	list_add_tail(>ue_ip_node, >ip_unwritten_list);
 	list_add_tail(>ue_node, >w_unwritten_list);
+	wc->w_unwritten_count++;
 	new = NULL;
 unlock:
 	spin_unlock(>ip_lock);
@@ -2238,7 +2242,7 @@ static int ocfs2_dio_get_block(struct inode *inode, sector_t iblock,
 		ue->ue_phys = desc->c_phys;
 
 		list_splice_tail_init(>w_unwritten_list, >dw_zero_list);
-		dwc->dw_zero_count++;
+		dwc->dw_zero_count += wc->w_unwritten_count;
 	}
 
 	ret = ocfs2_write_end_nolock(inode->i_mapping, pos, len, len, NULL, wc);
-- 
2.11.0



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

Bug#882181: mockito: FTBFS - java.lang.UnsupportedOperationException: Cannot nest operations in the same thread

[Markus Koschany]

Control: tags -1 confirmed

Am 20.11.2017 um 00:27 schrieb Gilles Filippini:
> Source: mockito
> Version: 1.10.19-2
> Severity: serious
> Justification: FTBFS
> 
> Hi,
> 
> While testing a build of mockito against a new json-simple releae I've
> experienced a FTBFS which is reproducible when building into a clean sid
> chroot:
> 
> Task :test class loader hash: 83f3637f6805a7b149525a93c5faad58
> Task :test actions class loader hash: d883a18cf154fc57e90f4d3fa9e5588f
> Executing task ':test' (up-to-date check took 0.041 secs) due to:
>   No history is available.
> Cannot nest operations in the same thread. Each nested operation must run in 
> its own thread.

[...]

Hi,

thanks for reporting. This appears to be the same issue Olivier Sallou
has mentioned on debian-java a few weeks ago. [1] This is a Gradle bug.
I'm not exactly sure why it is surfacing now. I am in the process of
updating Gradle to a newer version but it will take more time to finish
the work.

Regards,

Markus

[1] https://lists.debian.org/debian-java/2017/10/msg00078.html



signature.asc
Description: OpenPGP digital signature

Bug#882249: Welcome to Amazon - congrats penny fbKu

[Penny Stephens]

Please do nothing if this is going to cost me money. I dont have any. Thank
you

On Nov 20, 2017 2:14 PM, "thank you"  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#882261: rsyslog: imjournal doesn't work

[Goffredo Baroncelli]

Package: rsyslog
Version: 8.30.0-2ghigo1
Severity: important
Tags: upstream

When the imjournal module is used, rsyslog doesn't start. This is a know bug
which is fixed by commit 4736e53d471ac45024333588fcdf5bce5f8c61b8.

Note that if the imjournal is used, rsyslog hang and no log is recorded.

Starting manually, I got the following error messages

$ sudo rsyslogd
rsyslogd: sd_journal_next() failed: 'No such file or directory' [v8.30.0]

Depending by how systemd-journald is configured, this could means no log at 
all. This is the reason of the severity (important), even tough I have to admit 
that this is an uncommon configuration, so the occurence is very low.

BR
G.Baroncelli 


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

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

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.51
ii  libc62.24-17
ii  libestr0 0.1.10-2.1
ii  libfastjson4 0.99.7-1
ii  liblogging-stdlog0   1.0.6-1
ii  liblognorm5  2.0.3-1
ii  libsystemd0  235-3
ii  libuuid1 2.30.2-0.1
ii  lsb-base 9.20170808
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages rsyslog recommends:
ii  logrotate  3.11.0-0.1

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- Configuration Files:
/etc/rsyslog.conf changed:
module(load="imjournal" PersistStateInterval="100"
   StateFile="/var/log/rsyslog-imjournal.state") #load imjournal module
module(load="mmjsonparse") #load mmjsonparse module for structured logs
template(name="CEETemplate" type="string" 
string="%timegenerated:::date-rfc3339% %HOSTNAME% %syslogtag% @cee: 
%$!all-json%\n" ) #template for messages
action(type="mmjsonparse")
action(type="omfile" file="/var/log/cee.log" template="CEETemplate") 
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$WorkDirectory /var/spool/rsyslog
$IncludeConfig /etc/rsyslog.d/*.conf
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none  -/var/log/syslog
daemon.*-/var/log/daemon.log
kern.*  -/var/log/kern.log
lpr.*   -/var/log/lpr.log
mail.*  -/var/log/mail.log
user.*  -/var/log/user.log
mail.info   -/var/log/mail.info
mail.warn   -/var/log/mail.warn
mail.err/var/log/mail.err
news.crit   /var/log/news/news.crit
news.err/var/log/news/news.err
news.notice -/var/log/news/news.notice
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none  -/var/log/messages
*.emerg :omusrmsg:*
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/dev/xconsole
*.* /dev/tty12


-- no debconf information

Bug#882258: busybox: CVE-2017-16544: lineedit: do not tab-complete any strings which have control characters

[Christoph Biedl]

found 882258 1:1.20.0-7
found 882258 1:1.22.0-9+deb8u1
found 882258 1:1.22.0-19
found 882258 1:1.27.2-1
thanks

Salvatore Bonaccorso wrote...

> Please adjust the affected versions in the BTS as needed, only
> unstable checked so far.

Can help with that: All versions back to and including wheezy are
affected. Luckily the fix applies sanely everywhere, updated packages
will follow ASAP.

Christoph


signature.asc
Description: Digital signature

Bug#881149: htslib FTBFS: test failures on i386

[Graham Inggs]

Control: tags -1 + patch

I found the documentation of the optimization flags for GCC 7.2.0 [1].
I was then able to bisect the list of flags enabled for -O2 and
determine which ones needed to be disabled in order to build htslib on
i386.  Patch follows.

--- a/debian/rules
+++ b/debian/rules
@@ -7,7 +7,9 @@

 include /usr/share/dpkg/default.mk

-export DEB_CFLAGS_MAINT_APPEND = -fno-strict-aliasing
+ifneq (,$(filter $(DEB_HOST_ARCH),i386))
+  export DEB_CFLAGS_MAINT_APPEND=-fno-strict-aliasing -fno-code-hoisting
+endif

 %:


[1] https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Optimize-Options.html

Bug#588377: Fresh attempt on packaging dwarf-fortress

[Sven Bartscher]

Greetings,

Control: retitle -1 ITP: dwarf-fortress -- Slaves to Armok: God of Blood 
Chapter II: Dwarf Fortress

After this has been lying around for quite some time, I am planning on
making an attempt at packaging Dwarf Fortress. Status updates will
hopefully follow soon.

Regards
Sven


pgp38devtS_Q5.pgp
Description: Digitale Signatur von OpenPGP

Bug#882260: neutron-lbaas FTBFS: testtools.matchers._impl.MismatchError: 'www.hostfromdnsname1.com' != u'www.hostFromDNSName1.com'

[Adrian Bunk]

Source: neutron-lbaas
Version: 1:11.0.1-1
Severity: serious

Some recent change in unstable makes neutron-lbaas FTBFS:

https://tests.reproducible-builds.org/debian/history/neutron-lbaas.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron-lbaas.html

...
==
FAIL: 
neutron_lbaas.tests.unit.common.tls_utils.test_cert_parser.TestTLSParseUtils.test_alt_subject_name_parses
neutron_lbaas.tests.unit.common.tls_utils.test_cert_parser.TestTLSParseUtils.test_alt_subject_name_parses
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/neutron/tests/base.py", line 118, in 
func
return f(self, *args, **kwargs)
  File "neutron_lbaas/tests/unit/common/tls_utils/test_cert_parser.py", line 
243, in test_alt_subject_name_parses
self.assertEqual('www.hostfromdnsname1.com', hosts['dns_names'][0])
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in 
assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 'www.hostfromdnsname1.com' != 
u'www.hostFromDNSName1.com'


--
Ran 544 tests in 264.046s

FAILED (failures=1)
debian/rules:41: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#882259: ITP: charliecloud -- Lightweight user-defined software stacks for HPC

[Lucas Nussbaum]

Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum 

* Package name: charliecloud
  Version : 0.2.3~pre
  Upstream Author : Charliecloud team at Los Alamos National Labs
* URL : https://github.com/hpc/charliecloud
https://hpc.github.io/charliecloud
* License : Apache v2
  Programming Lang: C, Shell
  Description : Lightweight user-defined software stacks for HPC

Hi,

This is mainly to record my interest into packaging CharlieCloud, under
the umbrella of the Debian Science team. Help welcomed.

Lucas

Bug#882249: Welcome to Amazon - congrats Travis NI

[Travis Brewer]

I don't use Amazon. Please stop sending me junk mail

On Nov 20, 2017 1:14 PM, "thank you"  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Samuel Thibault]

Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> x86-64 libc in /lib64/). This package is not technically needed (because
> x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> installed nonetheless because of some dependencies.

The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
tried to do it in the past, just to see, with the same kind of effect as
you had.

The question is rather how that got pulled at all. What package thinks
it's a good idea to pull libc6-amd64?  Apart from libc64* packages
(which should normally not get pulled either), I can see uc-echo which
should rather use foreign dependencies, and :i386 multilib packages
which don't really make sense to install either.

I don't remember whether it was tried to make libc6-amd64:i386 conflict
with libc6:amd64 (and vice-versa for i386) to make sure that this
doesn't happen by misfortune?

Samuel

Bug#872251: libvoikko-dev is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

On Mon, Nov 20, 2017 at 01:23:07AM +0100, Manuel A. Fernandez Montecelo wrote:
>  
> https://anonscm.debian.org/cgit/collab-maint/libvoikko.git/commit/?id=94e7ce125739e59241c04034f5b0615e93c3cc49
> 
> Please review.  Explanations follow.

I don't think that this split makes sense as is.

Either you mark the new package M-A:foreign or you shouldn't split. If
some other package needs those tools, it certainly wants to execute
them. Thus it will need the build architecture version. In
build-depends, this can be achieved by annotating with :native or by
marking the package M-A:foreign (and the latter is wrong here). Thus
rdeps will have to put up with :native and that means you can simply
keep them together.

So marking the new package M-A:foreign may be an option. I'm not sure
whether it is correct. To figure out, someone should check whether the
tools *behave* the same on different architectures. If you feed them the
same input (input files, command line flags, environment, etc.), will
they have the same output? If the answer is "always yes", then
M-A:foreign is appropriate.

If M-A:foreign ends up being wrong, I'd not split at all, but simply
mark the -dev package M-A:no and update the relevant rdeps to use
:native.

If M-A:foreign ends up being correct, libvoikko-dev should actually
depend on the new package. Thus the full interface formerly provided by
libvoikko-dev keeps being provided by virtue of the dependency. But the
M-A headers will ensure that the library is for the host architecture
and the tools are for the build architecture. Consequently, I'd name the
package "libvoikko-dev-bin" and describe it as an implementation detail
of libvoikko-dev that you shouldn't use directly.

> Context: Contrary to the initial assumptions by Helmut, as I understood
> them, the binaries are not needed for compilation at all, they are not
> pre-processors or similar tools -- they are instead like "examples" or
> derived tools of the library, that others can use.  It's like if an XML
> library provides a parser or coloriser as a tool.

I don't know whether they are used, but if they aren't simply leaving
them in the -dev package and removing M-A:foreign is a solution.

> So my change splits the package to put the libraries (libvoikko-bin, not
> -dev-bin as initially suggested), makes -dev recommend it (for possible
> r-depends using it, like voikko-fi using the binary programs in rules),
> and -dev is marked as "Multi-Arch: same" while -bin one is not marked at
> all (implicit "no", IIRC).

As Adrian Bunk pointed out, the recommends can be ignored for most
practical things. So better make that a full dependency (as explained
above).

> However, I am not sure if a "M-A: same" recommending/depending on a
> "M-A: no" renders the ": same" unusable, please advise (esp. Helmut).

Yes, a dependency from a M-A:same package on a M-A:no package makes the
M-A:same annotation useless. That's why I say that you should split if
and only if the new package becomes M-A:foreign.

The "safe" route is removing M-A:foreign without splitting, because the
current use of M-A:foreign is clearly wrong and M-A:no pushes the
problem onto users.

Helmut

Bug#882258: busybox: CVE-2017-16544: lineedit: do not tab-complete any strings which have control characters

[Salvatore Bonaccorso]

Source: busybox
Version: 1:1.27.2-1
Severity: grave
Tags: security

Hi,

the following vulnerability was published for busybox. I realize you
know of the issue already but just filling to have a tracking bug as
well in the BTS.

CVE-2017-16544[0]:
| In the add_match function in libbb/lineedit.c in BusyBox through
| 1.27.2, the tab autocomplete feature of the shell, used to get a list
| of filenames in a directory, does not sanitize filenames and results in
| executing any escape sequence in the terminal. This could potentially
| result in code execution, arbitrary file writes, or other attacks.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-16544
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16544
[1] 
https://git.busybox.net/busybox/commit/?id=c3797d40a1c57352192c6106cc0f435e7d9c11e8

Please adjust the affected versions in the BTS as needed, only
unstable checked so far.

Regards,
Salvatore

Bug#882145: asterisk: pjsip show history causes segmentation fault

[Bernhard Schmidt]

Control: tags -1 + confirmed

On Sun, Nov 19, 2017 at 04:59:30PM +0100, Benoit Panizzon wrote:

Hi,

> I could reproduce apparently two different segmentation faults by doing the 
> following:
> 
> pjsip set history on
> pjsip show history
> 
> [8677620.301738] asterisk[24252]: segfault at 7fb6 ip 
> 7fb5f434426a sp 7fb623ffdf80 error 4 in 
> res_pjsip_history.so[7fb5f4341000+6000]
> [8677680.807810] asterisk[25015]: segfault at 7f22 ip 
> 7f21b822c26a sp 7f21ebffdf80 error 4 in 
> res_pjsip_history.so[7f21b8229000+6000]
> [8677741.313448] asterisk[25324]: segfault at 21000 ip 7f02251d8800 sp 
> 7f01a0f62788 error 4 in libc-2.24.so[7f0225158000+195000]
> 
> As I am on the task of migrating from chan_sip to pjsip, my only config at 
> the moment is one phone, just to figure out how pjsip exactly works:

FTR, I can reproduce this. The backtrace is 

0x7fff8d3a11d0 in sprint_list_entry (entry=entry@entry=0x55d91ff8, 
line=line@entry=0x7fffabc902b0 "[2001:4ca0:0:10a:215:65ff:feb7:4e7e]:11922", 
len=256) at res_pjsip_history.c:663
663 res_pjsip_history.c: No such file or directory.
(gdb) bt
#0  0x7fff8d3a11d0 in sprint_list_entry (entry=entry@entry=0x55d91ff8, 
line=line@entry=0x7fffabc902b0 "[2001:4ca0:0:10a:215:65ff:feb7:4e7e]:11922", 
len=256) at res_pjsip_history.c:663
#1  0x7fff8d3a24d3 in history_on_tx_msg (tdata=) at 
res_pjsip_history.c:711
#2  0x7fffd262321e in ?? () from /usr/lib/x86_64-linux-gnu/libpjsip.so.2
#3  0x7fffd2629a62 in pjsip_transport_send () from 
/usr/lib/x86_64-linux-gnu/libpjsip.so.2
#4  0x7fffd2624c53 in ?? () from /usr/lib/x86_64-linux-gnu/libpjsip.so.2
#5  0x7fffd2624f72 in ?? () from /usr/lib/x86_64-linux-gnu/libpjsip.so.2
#6  0x7fffd262824e in pjsip_resolve () from 
/usr/lib/x86_64-linux-gnu/libpjsip.so.2
#7  0x7fffd2626b4d in pjsip_endpt_send_request_stateless () from 
/usr/lib/x86_64-linux-gnu/libpjsip.so.2
#8  0x7fffd2636f6f in ?? () from /usr/lib/x86_64-linux-gnu/libpjsip.so.2
#9  0x7fffd2637456 in ?? () from /usr/lib/x86_64-linux-gnu/libpjsip.so.2
#10 0x7fffd26395b7 in pjsip_tsx_send_msg () from 
/usr/lib/x86_64-linux-gnu/libpjsip.so.2
#11 0x7fffd2639a8f in pjsip_endpt_send_request () from 
/usr/lib/x86_64-linux-gnu/libpjsip.so.2
#12 0x7fffaf99b319 in endpt_send_request 
(endpoint=endpoint@entry=0x55f5e058, tdata=tdata@entry=0x55f7bc68, 
timeout=timeout@entry=3000, token=token@entry=0x55ec7b58, 
cb=0x7fffaf99b510 ) at res_pjsip.c:3609
#13 0x7fffaf99dd58 in ast_sip_send_out_of_dialog_request 
(tdata=0x55f7bc68, endpoint=endpoint@entry=0x55f5e058, timeout=3000, 
token=token@entry=0x55fc8d08, 
callback=callback@entry=0x7fffaf9a1590 ) at 
res_pjsip.c:3756
#14 0x7fffaf9a12aa in qualify_contact (endpoint=endpoint@entry=0x0, 
contact=contact@entry=0x55fc8d08) at res_pjsip/pjsip_options.c:444
#15 0x7fffaf9a1533 in qualify_contact_task (obj=0x55fc8d08) at 
res_pjsip/pjsip_options.c:519
#16 0x556f80e8 in ast_taskprocessor_execute ()
#17 0x556ffd90 in ?? ()
#18 0x556f80e8 in ast_taskprocessor_execute ()
#19 0x556ff764 in ?? ()
#20 0x55707d7c in ?? ()
#21 0x75d4a494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#22 0x74954aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Unfortunately I did not find an obvious reason and I could not find an
upstream bug as well. 

I currently don't have much time to dive into this. If you have time
verifying this on sid would be helpful.

Bernhard

Bug#882249: Info received (Welcome to Amazon - congrats biglouerie PI)

[John Leuschen]

Problem take me off your list

On 20 Nov 2017 2:42 pm, "Debian Bug Tracking System" 
wrote:

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

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

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

Your message has been sent to the package maintainer(s):
 Debian Remote Maintainers 

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

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

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

Bug#882249: Welcome to Amazon - congrats NULL BIs1

[Theana Davidson]

Hi,
I downloaded the 2 documents but cannot open then having trouble with the
questionnaire and doc signature. Can you please help? I have Windows 7.

Thank you,
Theana Davidson

On Mon, Nov 20, 2017 at 12:14 PM, thank you  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#882249: Welcome to Amazon - congrats biglouerie PI

[John Leuschen]

Remove me from your crap


On 20 Nov 2017 2:14 pm, "thank you"  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#882249: Welcome to Amazon - congrats lisa 8cBy

[Lisa Duran]

REMOVE ME FROM YOUR EMAIL LIST

Kind regards,

Lisa G. Duran

On Nov 20, 2017 12:14 PM, "thank you"  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#882249: Welcome to Amazon - congrats james 8Oyz

[maginnessdonna]

See below recent scam for amazon or fraudsters prtending to be from amazon 
Regards 

Sent from my iPhone

> On 20 Nov 2017, at 17:14, thank you  wrote:
> 
> A Special Thankyou!
> 
> claim your amazonShopperReward
> 
> Thankyou for participating in our amazonquestionnaire. your feedback
> 
> about Amazon will earn you a special reward.
> 
> Thankyou for your opinion.
> 
> 
> Toberemoved fromreceivingfuturemail justgo here. 
> PO box 971, Reno NV 89504 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script 
> works for me to compile the xrdp pulse modules any time needed. Please test 
> and consider to ship it. In case shipping it is considered useful, please 
> update d/README.Debian accordingly. Wolfgang
> 

Bug#882249: Welcome to Amazon - congrats shaney nI

[Shaney]

Ok so if I go to that link then I will stop receiving the bullshit emails
from you guys saying Amazon wants me to take a survey and give me free
things that are completely unimportant and not even free- in return for a
survey?

The link in the last email I received doesn't work. Can you provide me with
a better one that works? Can you tell me how I can legitimately be
unsubscribed from ALL of this survey and bug tracking system crap please?
Or do I have to delete my Amazon account to do that? Information would be
nice since you've decided to contact me for some unknown reason.

I don't know why I'm receiving these emails and would like them to stop
please.

Thank you for your time.

Kind Regards,
Shaney

On Nov 20, 2017 2:14 PM, "thank you"  wrote:

> A Special Thankyou!
>
> claim your amazonShopperReward
>
> Thankyou for participating in our amazonquestionnaire. your feedback
>
> about Amazon will earn you a special reward.
>
> Thankyou for your opinion.
>
>
>
> 
> Toberemoved fromreceivingfuturemail justgo here.
> 
> PO box 971, Reno NV 89504
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
> works for me to compile the xrdp pulse modules any time needed. Please test
> and consider to ship it. In case shipping it is considered useful, please
> update d/README.Debian accordingly. Wolfgang

Bug#877086: service supervisor restart fails

[Peter Bittner]

We see a vary similar issue with supervisor 3.0r1-1+deb8u1 on Debian
8.9, even though the `restart` command seem to look alright (see
below).

Restarting the service fails (when the service is up beforehand),
because the Supervisor daemon seens to need some time to shut down.
Stopping and starting works fine, provided there passes some time
between their execution:

$ sudo service supervisor restart
Job for supervisor.service failed. See 'systemctl status
supervisor.service' and 'journalctl -xn' for details.
$ sudo service supervisor start
$ sudo service supervisor stop && sleep 1 && sudo service supervisor start


```
# FILE: /etc/init.d/supervisor
  restart)
echo -n "Restarting $DESC: "
start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
[ -n "$DODTIME" ] && sleep $DODTIME
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--startas $DAEMON -- $DAEMON_OPTS
echo "$NAME."
;;
```

Bug#882257: Ark (17.08.3-1): package has file conflicting with kde-l10n-ptbr

[Pino Toscano]

In data lunedì 20 novembre 2017 17:17:03 CET, Camarada Dennis ha scritto:
> Package: ark
> Version: 4:17.08.3-1
> Severity: normal
> Tags: l10n
> 
> Dear Maintainer,
> 
> upgrade of package ark on debian sid (17.08.3-1 over 16.08.3-2) failed
> while trying to overwrite file "/usr/share/doc/HTML/pt_BR/
> ark/ark-mainwindow.png",
> which is already part of the kde-l10n-ptbr (16.04.3-3) package.
> 
> Purging kde-l10n-ptbr allows finishing the ark upgrade.

Yes, this is already know, and being worked on -- see also
https://bugs.debian.org/882191

Please do not report other bugs, at least until I upload the new fixes
for all of them...

-- 
Pino Toscano

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

Bug#882249: Info received (Welcome to Amazon - congrats kamilovithars dO)

[kmilo Vithars]

El 20 nov. 2017 4:21 p. m., "Debian Bug Tracking System" <
ow...@bugs.debian.org> escribió:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Remote Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 882...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 882249: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882249
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#882249: Info received (Welcome to Amazon - congrats kamilovithars dO)

[kmilo Vithars]

El 20 nov. 2017 4:26 p. m., "kmilo Vithars" 
escribió:

>
> El 20 nov. 2017 4:21 p. m., "Debian Bug Tracking System" <
> ow...@bugs.debian.org> escribió:
>
>> Thank you for the additional information you have supplied regarding
>> this Bug report.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> interested parties for their attention; they will reply in due course.
>>
>> Your message has been sent to the package maintainer(s):
>>  Debian Remote Maintainers 
>>
>> If you wish to submit further information on this problem, please
>> send it to 882...@bugs.debian.org.
>>
>> Please do not send mail to ow...@bugs.debian.org unless you wish
>> to report a problem with the Bug-tracking system.
>>
>> --
>> 882249: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882249
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>>
>

Bug#882249: Info received (Welcome to Amazon - congrats kamilovithars dO)

[kmilo Vithars]

El 20 nov. 2017 4:21 p. m., "Debian Bug Tracking System" <
ow...@bugs.debian.org> escribió:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Remote Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 882...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 882249: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882249
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#882249: Welcome to Amazon - congrats Donald 2mY1

[Don Liming]

On Nov 20, 2017 1:25 PM, "Don Liming"  wrote:

> Please take me off your mailing list
>
> On Nov 20, 2017 1:24 PM, "Don Liming"  wrote:
>
>> Please take me off your mailing list
>>
>> On Nov 20, 2017 1:14 PM, "thank you"  wrote:
>>
>>> A Special Thankyou!
>>>
>>> claim your amazonShopperReward
>>>
>>> Thankyou for participating in our amazonquestionnaire. your feedback
>>>
>>> about Amazon will earn you a special reward.
>>>
>>> Thankyou for your opinion.
>>>
>>>
>>>
>>> 
>>> Toberemoved fromreceivingfuturemail justgo here.
>>> 
>>> PO box 971, Reno NV 89504
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached
>>> script works for me to compile the xrdp pulse modules any time needed.
>>> Please test and consider to ship it. In case shipping it is considered
>>> useful, please update d/README.Debian accordingly. Wolfgang
>>
>>

Bug#882249: Welcome to Amazon - congrats Donald 2mY1

[Don Liming]

I need proof that you are a part of Amazon

On Nov 20, 2017 1:26 PM, "Don Liming"  wrote:

>
> On Nov 20, 2017 1:25 PM, "Don Liming"  wrote:
>
>> Please take me off your mailing list
>>
>> On Nov 20, 2017 1:24 PM, "Don Liming"  wrote:
>>
>>> Please take me off your mailing list
>>>
>>> On Nov 20, 2017 1:14 PM, "thank you"  wrote:
>>>
 A Special Thankyou!

 claim your amazonShopperReward

 Thankyou for participating in our amazonquestionnaire. your feedback

 about Amazon will earn you a special reward.

 Thankyou for your opinion.



 
 Toberemoved fromreceivingfuturemail justgo here.
 
 PO box 971, Reno NV 89504



























































 Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached
 script works for me to compile the xrdp pulse modules any time needed.
 Please test and consider to ship it. In case shipping it is considered
 useful, please update d/README.Debian accordingly. Wolfgang
>>>
>>>

Bug#873411: kdevelop: Please update to llvm-toolchain 4.0 or, better, 5.0

[Pino Toscano]

Control: severity -1 important

(see below why...)

In data lunedì 20 novembre 2017 20:05:20 CET, Emilio Pozuelo Monfort ha scritto:
> Control: severity -1 serious
> 
> On Wed, 06 Sep 2017 21:34:47 +0200 Pino Toscano  wrote:
> > Hi,
> > 
> > In data domenica 27 agosto 2017 16:01:25 CEST, Sylvestre Ledru ha scritto:
> > > Source: kdevelop
> > > Severity: normal
> > > 
> > > Hello,
> > > 
> > > Currently, we have 6 versions of the llvm toolchain in the archive.
> > > I would like to move to 3 versions (4.0, 5.0 and snapshot, aka 6.0)
> > > 
> > > Could you please update your package to use 4.0 (or, better, 5.0 which 
> > > will be released very 
> > > soon)?
> > 
> > Sure, but only after the versions available build and work at least on
> > all the release architectures.  So far, llvm 3.9 is still affected by
> > #866354, since it did not build fine again since then -- this is
> > holding kdevelop in unstable for more than 2 months, and I really would
> > like to get it into testing.
> > 
> > I see that each of the llvm sources has various bugs, FTBFSes, cmake
> > issues, and so forth... as a suggestion from a bystander, what about
> > focusing on at most 3 versions of llvm in the archive, instead of
> > upload every version available (and then have to cleanup llvm users
> > periodically, like with bugs like this)?
> > 
> > > I will update the severity of this bug at the end of September
> > 
> > Doing that with the current state of llvm versions would be a bad idea.
> 
> It should be fine now with 4.0. Would be good if this could move to either
> unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. 
> Bumping
> to serious as we want to remove 3.8 soon to reduce the high number of llvm
> versions that we currently ship.

IMHO, if the goal would really be getting rid of old llvm versions in
the archive, then (as I wrote above) the llvm maintainers ought to
a) fix the latest stable (= 5.0)
b) switch llvm-defaults to the above

llvm got versioned symbols, so loading two llvm versions in the same
process (hello, mesa), although it is ugly. This should allow kdevelop
to switch back to llvm-defaults, even if llvm maintainers should care
a bit more about it, instead of almost letting it rot...

Anyway, I just lowered the severity of this bug to important, so
kdevelop 5.2 can migrate to testing.  Yes, it is an important update
(merged kdevplatform, so the separate source can be dropped), so I
really it to reach testing.
Because of another issue in the past, related to llvm (#866354),
kdevelop 5.1.x was stuck in unstable for basically 2 months. I don't
want llvm to get in the way of kdevelop, once again.

-- 
Pino Toscano

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

Bug#882249: Welcome to Amazon - congrats Donald 2mY1

[Don Liming]

Please take me off your mailing list

On Nov 20, 2017 1:24 PM, "Don Liming"  wrote:

> Please take me off your mailing list
>
> On Nov 20, 2017 1:14 PM, "thank you"  wrote:
>
>> A Special Thankyou!
>>
>> claim your amazonShopperReward
>>
>> Thankyou for participating in our amazonquestionnaire. your feedback
>>
>> about Amazon will earn you a special reward.
>>
>> Thankyou for your opinion.
>>
>>
>>
>> 
>> Toberemoved fromreceivingfuturemail justgo here.
>> 
>> PO box 971, Reno NV 89504
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Package: xrdp Version: 0.9.4-1 Severity: wishlist Hi, the attached script
>> works for me to compile the xrdp pulse modules any time needed. Please test
>> and consider to ship it. In case shipping it is considered useful, please
>> update d/README.Debian accordingly. Wolfgang
>
>