Bug#914576: RM: pentobi [armel mips mips64el ppc64el s390x] -- ROM; dependency qtwebview not available

[Juhani Numminen]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Pentobi 16.1-1, which was recently uploaded to unstable, now build-depends and
depends on Qt WebView and consequently can't be built on all the arches where
it was possible previously. I request this removal in order to allow the
supported architectures to migrate to testing.


Thanks,
Juhani Numminen

Bug#914558: petsc: hardcodes path to sh depending on build host

[Drew Parsons]

Source: petsc
Followup-For: Bug #914558

This is the first time I've heard of src-merge. Nice if it helps
manage containers.  But irreponsible to introduce it this late into
the Buster release cycle.

src-merge means the system is changed.  You build your package for a
given system, you expect it run on that system, you don't expect it to
run on a different system, or on an older system.  It's the same as a
library ABI or libc upgrade. All affected packages need to be rebuilt
to ensure the archive is running consistently. 

As far as I'm concerned this is not a petsc bug. You did the right
thing asking for a binNMU, thanks for that.

Drew

Bug#911542: ledgersmb: [INTL:it] Italian translation of debconf messages

[Robert J. Clay]

On Fri, Nov 23, 2018 at 12:59 PM Beatrice Torracca  wrote:
>
> Please find attached the Italian translation of ledgersmb debconf messages
> proofread by the Italian localization team.

The updated 'it.po' file has been imported into the package repository
[1] and will be included with the next package upload.   Many thanks!



-- 
Robert J. Clay
rjc...@gmail.com, j...@rocasa.us
[1] https://github.com/ledgersmb/pkg-ledgersmb

Bug#914575: libasound2: ALSA stopped working after updating libasound2 to 1.1.7

[Beta Version]

Package: libasound2
Version: 1.1.7-1
Severity: important

Dear Maintainer,

after updating libasound2 package to 1.1.7-1 version, ALSA stopped working in
Audacious player and Audacity audio editor. When trying to use ALSA output in
Audacious, it gives error: ALSA error: snd_pcm_open failed: Нет такого файла
или каталога.

Audacious terminal output:
ERROR alsa.cc:569 [open_mixer]: snd_mixer_find_selem failed.
WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0
for stream protocol
WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0
for stream protocol
WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0
for stream protocol
WARNING ffaudio-core.cc:188 [ffaudio_log_cb]: <(nil)> Invalid return value 0
for stream protocol
ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
ERROR util.cc:269 [audgui_simple_message]: ALSA error: snd_pcm_open failed: Нет
такого файла или каталога.

Pulseaudio output in Audacious works ok.

Audacity sound editor produce no sound and i can't choose other sound output,
except unworking ALSA.

Audacity terminal output:
ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
Cannot connect to server socket err = Нет такого файла или каталога
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
Cannot connect to server socket err = Нет такого файла или каталога
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
Expression 'alsa_snd_pcm_hw_params_set_period_size_near( pcm, hwParams,
,  )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line:
924
ALSA lib pcm_a52.c:823:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_dsnoop.c:638:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = Нет такого файла или каталога
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c',
line: 4628
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c',
line: 4628



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

Kernel: Linux 4.18.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU:ru (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#914574: xfce: With dual monitors, "extend to the right" setting is lost when monitors are power cycled

[James Van Zandt]

Package: xfce4
Version: 4.12.4
Severity: normal
File: xfce

Dear Maintainer,

I have a dual monitor setup, normally configured with "extend to the
right".  I leave the computer running all the time, but I power down
the monitors when I'm not using them.  Every time I turn them on, or
after several minutes with no activity, the system has reverted to
"mirrored displays", and a four-panel dialog is displayed with these
choices:

  1. ASUS 27"
  Mirror Displays
  Extend to the right
  2. ASUS 27"

What I expected is to set up the displays once, navigating
  Applications -> Settings -> Displays
and unsetting "Mirror displays".  After that, the settings should be
preserved across monitor power-cycles, periods of inactivity, and
system restarts.

(I'm attaching screenshots of the two dialogs.)

I see the setting is stored as the relative position of the second
monitor in
  ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml:

diff -r -U 8 xfce4-extended/xfconf/xfce-perchannel-xml/displays.xml
xfce4-mirrored/xfconf/xfce-perchannel-xml/displays.xml
--- xfce4-extended/xfconf/xfce-perchannel-xml/displays.xml
2018-11-24 22:49:22.814745510 -0500
+++ xfce4-mirrored/xfconf/xfce-perchannel-xml/displays.xml
2018-11-24 23:09:02.810708537 -0500
@@ -77,15 +77,15 @@
 
   
   
   
   
   
   
   
-
+
 
   
 
   
   
 

Power cycling the monitors resets the X coordinate of the Position to zero.

Incidentally, I tried both "Configure new displays when connected"
settings.  The only difference was that when this was not set, the
four-panel dialog was not displayed when the monitors were turned on,
and I had to navigate to the normal display dialog instead.  This
suggests it's not remembering the monitors - i.e. every time it wakes
up, it thinks I've installed new monitors.  Where is that part of the
configuration supposed to be saved?

   - Jim Van Zandt



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

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-3
ii  libxfce4ui-utils 4.12.1-3
ii  orage4.12.1-4
ii  thunar   1.8.2-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.4.1-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.4-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-2
ii  xfwm44.12.5-1

Versions of packages xfce4 recommends:
ii  desktop-base  9.0.7
ii  tango-icon-theme  0.8.90-7
ii  thunar-volman 0.9.0-1
ii  xfce4-notifyd 0.4.2-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
ii  xfce4-goodies4.12.5
ii  xfce4-power-manager  1.6.1-1

-- no debconf information

Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: mongo-cxx-driver
  Version : 3.4.0
  Upstream Author : Mongo C++ Driver Team 

* URL : http://mongocxx.org/
* License : Apache License 2.0
  Programming Lang: C++
  Description : MongoDB C++ client library

libmongocxx is the officially supported MongoDB client library for C++
applications.

This package will be maintained by the upstream development team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAlv6ICYACgkQLNd4Xt2n
sg/rEw/+K1c56nrVyuD/pvKu7hvfrIdbv2NYtTzi6Pkxx8mgaWghE+xNGninaEpi
9kxZqeTLeSH/FDzJuN/9ZvCcR7p+muoDBX70sRt+bKoDTq1BTCTmIflm9E/XjA0n
01R4+QtYhNgtkFR9XMuThTTei9xamDVLrsguTr4PzN+u0b1/iWZUV1ZCsWoxKJtq
T5BiqGWUtiD0r1VpyTgsrU5CEY+WbKgTVVhAJc4pFFP1BporUwXaCGiyMbmmpiX9
D8RsV9c3CUDPmiLaGIGcX8Ejuy/mM2DOZLIGfI9K4oWuiSKpaTVk+Nrz9RYZ+dGZ
0hb32qtZOJO9rX7SzNS87hCxSRaIKDUtd9AvNHHhaYgBHUExTTNeiXFJrz8CICnG
vefH8+9TyK6VQvnJ1gmYS20/M538fA9mT/70pAnMezTiplCy2m43KeE9RIryNH/Z
qgh9IXGO0zmSq/YkdSp8tRXbf5uKmxTPZavZj3HVeMAAH9BwpNLit2VvmYSvHbB0
4P5PjfOBJ6iQCJNmYQY0VLPq9FKRmBaUZVTwI+jB3zcj5K0zFcUFPLBrCGeY4DEu
QUXWowsBYy3zm99eC/So48neMRVGIB+pGgs6TGzSMbL+Aoou77DKhZKpVajrw1/C
eN+zFrTYHMcI+XL/adKsTuRPq3S8xP32xeRwAgvoP3F7RnIGlGI=
=qTa1
-END PGP SIGNATURE-

Bug#914572: RM: eclipse-emf-examples [all] -- RoQA; cruft arch:all binary package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: eclipse-...@packages.debian.org
Affects: src:eclipse-emf

eclipse-emf-examples is an arch:all binary package that is no longer
built from source by the eclipse-emf source package. Please remove the
binary package.

Thanks,
Jeremy Bicha

Bug#914570: RM: eclipse-emf [all] -- RoQA; cruft arch:all binary package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: eclipse-...@packages.debian.org
Affects: src:eclipse-emf
Control: block 914448 by -1

eclipse-emf is an arch:all binary package that is no longer built from
source by the eclipse-emf source package. Please remove the binary
package.

Thanks,
Jeremy Bicha

Bug#914571: RM: eclipse-emf-sdk [all] -- RoQA; cruft arch:all binary package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: eclipse-...@packages.debian.org
Affects: src:eclipse-emf
Control: block 914448 by -1

eclipse-emf-sdk is an arch:all binary package that is no longer built
from source by the eclipse-emf source package. Please remove the
binary package.

I hope it's not a problem that I'm filing 3 of these bugs. The other 2
binary packages are eclipse-emf and eclipse-emf-examples

Thanks,
Jeremy Bicha

Bug#914569: beets: zsh completion broken

[Clint Adams]

Source: beets
Version: 1.4.7-2

% beet import ../
_beet:zregexparse:4: invalid regex : )

(with zsh 5.6.2-3)

Bug#914448: RM: eclipse -- ROM; Old and unmaintained, replaced by finer-grained libraries

[Jeremy Bicha]

libequinox-osgi-java is now shipped in its own source package so you
can safely ignore its reverse dependencies.

Thanks,
Jeremy Bicha

Bug#914568: emacs25: Please build with xwidget support

[John Goerzen]

Package: emacs25
Version: 25.1+1-4+deb9u1
Severity: normal

Hi,

Over at
https://www.gnu.org/software/emacs/manual/html_node/emacs/Embedded-WebKit-Widgets.html
, the xwidget-webkit-browse-url function is documented.

C-h a also lists it, and it is apparently defined in xwidget.el.

However, when I run M-x xwidget-webkit-browse-url, I get: "Your Emacs
was not compiled with xwidgets support"

Thanks,

John


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

Kernel: Linux 4.9.0-8-amd64 (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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs25 depends on:
ii  emacs25-bin-common 25.1+1-4+deb9u1
ii  gconf-service  3.2.6-4+b1
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.3-5
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11+deb9u3
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libdbus-1-31.10.26-0+deb9u1
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgconf-2-4   3.2.6-4+b1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libgif75.1.4-0.4
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u3
ii  libgomp1   6.3.0-18+deb9u1
ii  libgpm21.20.4-6.2+b1
ii  libgtk-3-0 3.22.11-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.1-2
ii  libm17n-0  1.7.0-3+b1
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11+deb9u5
ii  libotf00.9.13-3+b1
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpng16-161.6.28-1
ii  librsvg2-2 2.40.16-1+b1
ii  libselinux12.6-3+b3
ii  libsm6 2:1.2.2-1+b3
ii  libtiff5   4.0.8-2+deb9u2
ii  libtinfo5  6.0+20161126-1+deb9u2
ii  libx11-6   2:1.6.4-3
ii  libx11-xcb12:1.6.4-3
ii  libxcb11.12-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-1+b2
ii  libxinerama1   2:1.1.3-1+b3
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

emacs25 recommends no packages.

Versions of packages emacs25 suggests:
ii  emacs25-common-non-dfsg  25.1+1-1

-- no debconf information

Bug#912117: to_dict failure

[Mahmoud Hashemi]

Hey Adrian/all, upstream maintainer here, just wanted to say this is on my
radar. TL;DR Python 3.7 semi-quietly (as part of a separate bugfix) changed
the dict constructor behavior when passed another dict. Tracking it here:
https://github.com/mahmoud/boltons/issues/179

Thanks!

Mahmoud

Bug#833116: fgetty: Incorrect keystroke interpretation

[Dmitry Bogatov]

control: tags -1 moreinfo

[2016-08-10 14:40] Ricardo Fabian Peliquero 
> You are right.
> 
> It seems to me now that is more a libreadline6/libtinfo5 problem than
> especifically of fgetty/login1.

Hi, two years after, with libreadline8 in archives, does problem still
persist?

Bug#823485: kernel: brcmsmac bcma0:1: START: tid 1 is not agg'able

[Darsey Litzenberger]

I'm seeing the same thing on a MacBookAir5,2 device with this hardware:

02:00.0 Network controller [0280]: Broadcom Limited BCM43224 802.11a/b/g/n 
[14e4:4353] (rev 01)
   Subsystem: Apple Inc. AirPort Extreme [106b:00e9]
   Flags: bus master, fast devsel, latency 0, IRQ 17
   Memory at a040 (64-bit, non-prefetchable) [size=16K]
   Capabilities: [40] Power Management version 3
   Capabilities: [58] Vendor Specific Information: Len=78 
   Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
   Capabilities: [d0] Express Endpoint, MSI 00
   Capabilities: [100] Advanced Error Reporting
   Capabilities: [13c] Virtual Channel
   Capabilities: [160] Device Serial Number 7a-79-c3-ff-ff-da-7c-d1
   Capabilities: [16c] Power Budgeting 
   Kernel driver in use: bcma-pci-bridge
   Kernel modules: bcma

The device seems to work fine (I'm filling out this bug report over ssh) 
but this spams the kernel log multiple times per second.  This patch 
from wireless-drivers-next looks like it could help:


https://patchwork.kernel.org/patch/10653373/
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=96fca788e5788b7ea3b0050eb35a343637e0a465

commit 96fca788e5788b7ea3b0050eb35a343637e0a465
Author: Ali MJ Al-Nasrawy 
Date:   Tue Oct 23 19:12:35 2018 +0300

   brcmsmac: never log "tid x is not agg'able" by default

   This message greatly spams the log under heavy Tx of frames with BK access
   class which is especially true when operating as AP. It is also not 
informative
   as the "agg'ablity" of TIDs are set once and never change.
   Fix this by logging only in debug mode.

   Signed-off-by: Ali MJ Al-Nasrawy 
   Signed-off-by: Kalle Valo 

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
index 81ff558046a8..6188275b17e5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
@@ -846,8 +846,8 @@ brcms_ops_ampdu_action(struct ieee80211_hw *hw,
   status = brcms_c_aggregatable(wl->wlc, tid);
   spin_unlock_bh(>lock);
   if (!status) {
-   brcms_err(wl->wlc->hw->d11core,
- "START: tid %d is not agg\'able\n", tid);
+   brcms_dbg_ht(wl->wlc->hw->d11core,
+"START: tid %d is not agg\'able\n", tid);
   return -EINVAL;
   }
   ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);

Bug#914316: Fixed in gcc-8 8.2.0-10

[Michael Biebl]

On Sat, 24 Nov 2018 09:33:11 +0100 Sven Joachim  wrote:
> Source: gcc-8
> Version: 8.2.0-10
> 
> The miscompilation of mesa has been fixed in the latest gcc-8 upload,
> please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 for
> details.

I recompiled mesa with 8.2.0-10 and I can confirm the fix.

Andreas, thank you for the quick mesa update! Feel free to drop my
workaround again in one of your next uploads.

Regards,
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#914567: debian-security-support: mark webkit2gtk as having limited support

[John Scott]

Package: debian-security-support
Version: 2018.06.08
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have WebKitGTK+ installed and thought it was odd that
check-security-support didn't have anything to say. Notes
on the Debian security tracker [1] indicate that webkit2gtk
isn't covered by security support.

Assuming this is correct, I think duplicating the entry
for webkitgtk is fine, except possibly removing the note
about backports being infeasible since they appear to be
regularly updated in Stretch [2] and to a lesser extent
in Jessie.

[1] https://security-tracker.debian.org/tracker/source-package/webkit2gtk
[2] https://packages.debian.org/source/stretch-backports/webkit2gtk

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

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

Versions of packages debian-security-support depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  gettext-base   0.19.8.1-9

debian-security-support recommends no packages.

debian-security-support suggests no packages.

- -- debconf information:
  debian-security-support/ended:
  debian-security-support/earlyend:
  debian-security-support/limited:

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEAXEkn09uX7g8Tv8W3qerYfa4vJcFAlv57PgACgkQ3qerYfa4
vJd4DQgAksPAxUi3K9nNih14e95lyFDyKtHABgjwiWfLpGvcAMkakVxt3LHTsAvj
v//HGqYOYkS+UoUnadBdn8KXyDipmupP19/wWQ0l65ZuWVUqC7rwlCQVsEDc45pF
K/iKPLw8WoxkTBxw1kMTm9YN1IfbqlH0byf6GEQJOgB+YCIIz8es+Sa8+UplVg9I
mzkJ3HfeFHt84myLwhomKtGFPD4+do3s56n7oS7oHUg7pXAhgDje9URZaewBzjJU
bftC9YyiNzpdiqXuTTUv6W8YwC6BnkwOd96s0QSsXYCF8dwPFNfxRlWvdKlCNsRF
gnuZoq6gaSVjU5npRYSUibsowbz44w==
=pfPA
-END PGP SIGNATURE-

Bug#914566: RM: pleiades -- ROM; No longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the pleiades package. It contains a Japanese translation plug-in
for Eclipse but it's about to be removed (#914448).

Thank you,

Emmanuel Bourg

Bug#914512: php-apcu: Rename to php7.2-apcu?

[Daniel Lo Nigro]

How are the versions determined? The issue I have at the moment is that the
version of *php-apcu* in buster (5.1.12+4.0.11-2) is not compatible with
the version of *php7.2-fpm* in buster. It looks like the current version of
php-apcu only supports the RC of PHP 7.3, not the current released version
of PHP (7.2). I had to compile php-apcu manually from source to get it
working properly, as installing php-apcu was trying to install PHP 7.3 too.

--
Regards,
Daniel Lo Nigro
https://d.sb/ | Twitter  | Facebook



On Sat, Nov 24, 2018 at 3:30 AM Ondřej Surý  wrote:

> php-apcu is a PECL extension that gets compiled for all available version
> from the Debian (driven by php-all-dev package from src:php-defaults).
>
> This allows smooth transitions from one PHP version to another.
>
> So, what I am saying this works as intended, the phpX.Y-ext is reserved
> solely for extensions shipped inside PHP (e.g. native extensions).
>
> Ondřej
> --
> Ondřej Surý 
>
> > On 24 Nov 2018, at 08:58, Daniel Lo Nigro  wrote:
> >
> > Package: php-apcu
> > Version: 5.1.12+4.0.11-2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Most of the other PHP packages are prefixed with the version number, for
> example "php7.2-gd", "php7.2-curl", etc. This allows multiple PHP versions
> to be installed side-by-side.
> >
> > However, the APCU package is just called "php-apcu". Is there a reason
> for this difference? It means I'm unable to have PHP 7.1 and 7.2 installed
> side-by-side each with a packaged version of apcu, and instead need to
> build from source.
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >  APT prefers testing
> >  APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages php-apcu depends on:
> > ii  libc62.27-8
> > ii  php-common   1:62
> > ii  php7.3-cli [phpapi-20180731] 7.3.0~rc4-1
> > ii  php7.3-phpdbg [phpapi-20180731]  7.3.0~rc4-1
> >
> > Versions of packages php-apcu recommends:
> > ii  php-apcu-bc  1.0.4-3
> >
> > Versions of packages php-apcu suggests:
> > ii  php7.1-gd [php-gd]  7.1.16-1
> > ii  php7.2-gd [php-gd]  7.2.4-1
> >
> > -- no debconf information
> >
>
>

Bug#914565: php7.3-intl: Segfaults after apache2 graceful restart

[Dino]

Package: php7.3-intl
Version: 7.3.0~rc5-2
Severity: important

Dear Maintainer,

After a graceful restart of apache2 the server stops working. Since the 
graceful restart happens every night by default, this renders the server more 
or less unusable.

The logs show the following after reloading the service:

/var/log/apache2/error.log.1
/var/log/apache2/error.log.1
[Fri Nov 23 00:00:01.526101 2018] [mpm_prefork:notice] [pid 2858]
AH00171: Graceful restart requested, doing restart

/var/log/apache2/error.log
[Fri Nov 23 00:00:01.622137 2018] [mpm_prefork:notice] [pid 2858]
AH00163: Apache/2.4.37 (Debian) OpenSSL/1.1.1 configured -- resuming
normal operations
[Fri Nov 23 00:00:01.622156 2018] [core:notice] [pid 2858] AH00094:
Command line: '/usr/sbin/apache2'
[Fri Nov 23 00:00:01.626193 2018] [core:notice] [pid 2858] AH00052:
child pid 5383 exit signal Segmentation fault (11)
[Fri Nov 23 00:00:01.626217 2018] [core:notice] [pid 2858] AH00052:
child pid 5384 exit signal Segmentation fault (11)
[Fri Nov 23 00:00:01.626222 2018] [core:notice] [pid 2858] AH00052:
child pid 5385 exit signal Segmentation fault (11)
[Fri Nov 23 00:00:01.626227 2018] [core:notice] [pid 2858] AH00052:
child pid 5386 exit signal Segmentation fault (11)

These segmentation faults keep going so that the error.log file grows
to hundreds of MB within a few hours.

After doing "service apache2 restart" the server works properly again.

I attached gdb to the process and the backtrace always leads to intl.so:

(gdb) c
Continuing.
[New process 4876]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Thread 2.1 "apache2" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fe37f71f440 (LWP 4876)]
0x7fe377a87660 in ?? () from target:/usr/lib/php/20180731/intl.so
(gdb) bt
#0  0x7fe377a87660 in ?? () from target:/usr/lib/php/20180731/intl.so
#1  0x7fe37f87670e in __libc_fork () at ../sysdeps/nptl/fork.c:204
#2  0x7fe37f6755c5 in make_child (s=0x7fe37f7074a0, slot=0, bucket=0) at 
prefork.c:665
#3  0x7fe37f6763f5 in perform_idle_server_maintenance (p=) 
at prefork.c:824
#4  prefork_run (_pconf=, plog=, s=) at prefork.c:1019
#5  0x55d9dc84f60e in ap_run_mpm (pconf=0x7fe37fa7a028, 
plog=0x7fe37f700028, s=0x7fe37f7074a0) at mpm_common.c:94
#6  0x55d9dc847f47 in main (argc=, argv=) at 
main.c:819

apache2 is configured by certbot to use SSL/TLS. Apart from that, the 
configuration is not altered.

Best,
Dino

-- Package-specific info:
 Additional PHP 7.3 information 

 PHP @PHP_VERSION SAPI (php7.3query -S): 

 PHP 7.3 Extensions (php7.3query -M -v): 

 Configuration files: 
 /etc/php/7.3/mods-available/intl.ini 
extension=intl.so


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

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

Versions of packages php7.3-intl depends on:
ii  libc6  2.27-8
ii  libgcc11:8.2.0-9
ii  libicu63   63.1-4
ii  libstdc++6 8.2.0-9
ii  php-common 2:68
ii  php7.3-common  7.3.0~rc5-2
ii  ucf3.0038

php7.3-intl recommends no packages.

php7.3-intl suggests no packages.

Versions of packages php7.3-common depends on:
ii  libc6   2.27-8
ii  libssl1.1   1.1.1-2
ii  php-common  2:68
ii  ucf 3.0038

Versions of packages php7.3-cli depends on:
ii  libargon2-1  0~20171227-0.1
ii  libc62.27-8
ii  libedit2 3.1-20180525-1
ii  libmagic11:5.34-2
ii  libpcre2-8-0 10.32-3
ii  libsodium23  1.0.16-2
ii  libssl1.11.1.1-2
ii  libxml2  2.9.4+dfsg1-7+b2
ii  mime-support 3.61
ii  php7.3-common7.3.0~rc5-2
ii  php7.3-json  7.3.0~rc5-2
ii  php7.3-opcache   7.3.0~rc5-2
ii  php7.3-readline  7.3.0~rc5-2
ii  tzdata   2018g-1
ii  ucf  3.0038
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages php7.3-cli suggests:
pn  php-pear  

Versions of packages libapache2-mod-php7.3 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.37-1
ii  libargon2-1 0~20171227-0.1
ii  libc6   2.27-8
ii  libmagic1   1:5.34-2
ii  libpcre2-8-010.32-3
ii  libsodium23 1.0.16-2
ii  libssl1.1   1.1.1-2
ii  libxml2 2.9.4+dfsg1-7+b2
ii  mime-support3.61
ii  php7.3-cli  7.3.0~rc5-2
ii  php7.3-common   7.3.0~rc5-2
ii  php7.3-json 7.3.0~rc5-2
ii  php7.3-opcache  7.3.0~rc5-2
ii  tzdata  2018g-1
ii  

Bug#905080: O: as31 - Intel 8031/8051 assembler

[Albert van der Horst]

Bdale Garbee schreef op 2018-07-31 07:17:

Package: wnpp
Severity normal

I no longer have any personal need for as31, so would like to drop it
from the list of packages I maintain.

I recently uploaded a fix for the segfault encountered building the
usbdux driver in the firmware-nonfree source package.  The only
remaining open bug regards the ambiguity of upstream asserting the
package is under "the BSD license" without specifying which precise
variant.

To the best of my knowledge, no packages in Debian depend on as31, but
because there is a driver (that is not built for Debian by default) in
the firmware-nonfree package that depends on it, I choose to orphan the
package rather than just asking for it to be removed from the archive.


I looked into this package and the upstream archive just exists.
Moreover the package is up to date w.r.t. upstream since 2005. 
Apparently

this is a superstable package where the last bugs disappeared ages ago.

I would regret if this package disappears from Debian, because
- the 8051 has historic interest, but also to this day practical 
interest
- the assembler is a solid piece of software engineering, so it is worth 
 maintaining and probably not overly time consuming.
- if nothing else, it can serve as an example of the use of lex and 
yacc.


After studying the project I'm willing to take on the orphaned 8051
assembler as31.

My credentials:
- dedicated to the free software movement (author of some free software)
- unix/c experience since the 80's
- sworn in as a maintainer at debian mentors (thanks, Geert Stappers!)
- some experience with Debian packaging, and some familiarity with
  the policy and guidelines
- extensive experience with software maintenance (as well as 
development)
- affinity with the 8051, owner of dozens of single board computers, 
among

them a couple 8051 based
- Published a flash programmer for an Elektor board with a 8051 
processor:

https://forth.hcc.nl/w/Producten/Flash
- a direct personal line to Willem Ouwerkerk, creator of a 8051 
development

   system




Bdale


Groetjes Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Bug#914564: dh_makefont: invalid choice: 'reateorig'

[Adam Borowski]

Package: dh-make
Version: 2.201801
Severity: normal

Hi!
Attempting to run dh_makefont results in:

usage: dh_make [-h] [-a] [-c ] [--copyrightfile ] [-d] [--docs]
   [-e ] [-f ] [-n] [-o ] [-p ]
   [-t ] [-y] [--createorig] [--with-emacs]
   [-C  | -s | -i | -l | --python] [-v]
dh_make: error: argument -c/--copyright: invalid choice: 'reateorig' (choose 
from 'apache', 'artistic', 'bsd', 'gpl', 'gpl2', 'gpl3', 'isc', 'lgpl', 
'lgpl2', 'lgpl3', 'mit', 'custom')
dh_makefont: dh_make died so I die.

Same happens no matter whether I give it a -c with some argument or nothing
at all.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-00181-g78c96551b096 (SMP w/4 CPU cores; PREEMPT)
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 dh-make depends on:
ii  debhelper  11.5.3
ii  dpkg-dev   1.19.2
ii  make   4.2.1-1.2
ii  python33.6.7-1

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  12.5

-- no debconf information

Bug#913287: Bug#912925: Is the SONAME the same for all the related libs?

[Lisandro Damián Nicanor Pérez Meyer]

El sáb., 24 nov. 2018 15:19, Julian Gilbey  escribió:

> On Fri, Nov 23, 2018 at 10:07:47AM -0300, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Hi Julian!
> >
> > El jueves, 22 de noviembre de 2018 21:54:30 -03 Julian Gilbey escribió:
> > > On Sun, Nov 18, 2018 at 03:35:11PM +, Julian Gilbey wrote:
> > > > On Sun, Nov 18, 2018 at 09:01:19AM -0300, Lisandro Damián Nicanor
> Pérez
> > Meyer wrote:
> > > > > Yesterday I've uploaded qtbase with this fix, please try it.
> > > >
> > > > Excellent, thanks!  I just built it on my testing machine, and it
> > > > worked perfectly with the Python script in this bug report and the
> > > > simplebrowser example.
> > >
> > > Hi Lisandro,
> > >
> > > Upstream have now patched what-I-presume-will-become 5.12.1 with
> > > almost this patch.  But it's gone through several iterations, and now
> > > the patch also deletes a couple of #include's.  See patch set #7 at
> > > https://codereview.qt-project.org/#/c/245294/
> > >
> > > I doubt it's worth uploading a new version just for this, but when you
> > > are doing the next qtbase upload, you might consider making this
> > > change.
> >
> > That's exactly the patch with which I closed this bug. This is already
> in the
> > archive. Enjoy!
>
> Hi Lisandro,
>
> Version 7 of the patch is slightly different from the one you applied
> to the archive: it also removes some conditional #includes. But it is
> probably unimportant for Debian.




Thank you for the clarification. Dmitry made me note the same thing, and
yes, is unimportant.

>

Bug#907429: neverball: Constant fsync calls seriously degrade performance

[Ryan C. Gordon]

I tried this and can confirm that removing setBuffer calls avoids the
fsyncs. I verified this with strace too, which should be doable on any
machine (just "strace -o /tmp/output ./neverball", and after playing
check that /tmp/output contains no fsync calls).


Cool, I know how to fix this now, thank you!

--ryan.

Bug#913237: xterm: exec-formatted yields a tilde character in zsh and emacs

[Vincent Lefevre]

On 2018-11-21 19:02:33 -0500, Thomas Dickey wrote:
> I don't see how this could happen unless you combined the action with
> some pasting (such as bracketed-paste).

I paste nothing.

> xterm's formatting of the string is shell-agnostic, and the exec'd
> "browser" command would only depend on what the formatted URL looked
> like.
> 
> In either case, steps-to-reproduce seem obscure.

With zsh, one can reproduce the issue with:

$ xterm -e zsh -f

then in the xterm:

zira% bindkey -e

What's strange is that in the Xterm log, I can get either ^G~, or
just ~, or nothing.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#914373: octave-statistics: accessing installed functions is needlessly obscure

[James Van Zandt]

I don't see why a Readme.DEBIAN file in each package would be
difficult to manage.  If needed, it could be generic, with the
same text in each package, such as:

By default installed packages are not available from the Octave
prompt.  The functions from this package can be added to the Octave
path by typing

 pkg load 

at the Octave command line.

I note a discussion of autoloading packages here:
http://octave.1599824.n4.nabble.com/package-autoload-td4676287.html

particularly a comment by LachlanA;

> My personal belief is that the __unimplemented__ function, which
> currently tells us which package we should load, should just load
> the package and continue (unless the same function is implemented
> in multiple packages, in which case it should list all of those
> packages and give an error).
>
> That would most closely emulate the Matlab experience, while
> avoiding the problems Carnë described.

I would appreciate that.  However, I'd be satisfied if the
__unimplemented__ function simply knew about all the functions available in
packages.  (Currently it doesn't - the subject of another bug).


On Sat, Nov 24, 2018 at 5:43 AM Rafael Laboissière 
wrote:

> [Moving this discussion from Bug#914373 into debian-octave.]
>
> * James Van Zandt  [2018-11-22 13:34]:
> >
> > [snip]
> >
> > Please provide a file /usr/share/doc/octave-statistics/README.Debian
> > with a note something like
> >
> >By default installed packages are not available from the Octave
> >prompt.  The functions from this package can be added to the Octave
> >path by typing
> >
> > pkg load statistics
> >
> >at the Octave command line.
> >
> > [snip]
>
> The bug reporter also suggests to add README.Debian files for all
> other OF packages.
>
> Do the other members of the DOG agree with this change?
>
> Rafael
>

Bug#822761: Image Select Dialog Broken

[Jonathan Hutchins]

This happens to me on a jessie-squeeze upgrade as well.  The dialog 
defaults to only selecting a folder and can't be changed to select a 
file; subfolders are not browseable.


--
Jonathan

Bug#914563: transition: alglib

[Anton Gladky]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition


Dear release team,

please provide a slot for the transition of the new alglib
version 3.14.

All build reverse-depenencies of the package are building fine
with this new version.


Thanks,

  Anton

===
Ben file:

title = "alglib";
is_affected = .depends ~ "libalglib3.11" | .depends ~ "libalglib3.14";
is_good = .depends ~ "libalglib3.14";
is_bad = .depends ~ "libalglib3.11";


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

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

Bug#914562: lintian: please decide on Debian Enhancement Proposal spelling (harmonise)

[Thorsten Glaser]

Package: lintian
Version: 2.5.112
Severity: wishlist

I found this:

/usr/share/lintian/checks/patch-systems.desc:Info: The patch contains a 
standard DEP-3 template description

vs.

/usr/share/lintian/checks/upstream-metadata.desc:Info: The DEP 12 metadata file 
in the source is not readable.  This

I also carry the DEPs in my acronyms database, but I would like to
avoid repeating them as “DEP 3”, “DEP-3”, “DEP3” and use only one
spelling of them.

Personally I’d prefer DEP-3, but the http://dep.debian.net/ site
uses “DEP 3” spelling (with ASCII space in between), except in
the URLs which have “dep3”.

Please d̲o̲ contact the and interact with the people behind the DEP
system; I’ve just reported this against lintian because it often
refers people to one or another DEP and therefore is probably the
most visible place for their spelling.


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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-7
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.11-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.75+repack-1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.0-4
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-7
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information

Bug#914557: thunderbird: Version 1:60.3.0-1+b1 is not installable (breaks lightning and various calendar)

[Carsten Schoenert]

Hello Eric,

please please check the BTS before creating a new issue!
This is already reported as #914175.

Am 24.11.18 um 23:02 schrieb Eric Valette:
> Package: thunderbird
> Version: 1:60.3.0-1+b1
> Severity: important
> 
> LANG=C apt-get -s install thunderbird
> NOTE: This is only a simulation!
>   apt-get needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Recommended packages:
>   lightning
> The following packages will be REMOVED:
>   calendar-exchange-provider calendar-google-provider lightning
> The following packages will be upgraded:
>   thunderbird
> 1 upgraded, 0 newly installed, 3 to remove and 5 not upgraded.
> Remv calendar-exchange-provider [5.0.0~alpha1-1]
> Remv calendar-google-provider [1:60.3.0-1]
> Remv lightning [1:60.3.0-1]
> Inst thunderbird [1:60.3.0-1] (1:60.3.0-1+b1 Debian:unstable [amd64])
> Conf thunderbird (1:60.3.0-1+b1 Debian:unstable [amd64])

-- 
Regards
Carsten Schoenert

Bug#914557: thunderbird: Version 1:60.3.0-1+b1 is not installable (breaks lightning and various calendar)

[Eric Valette]

On 24/11/2018 23:27, Carsten Schoenert wrote:

Hello Eric,

please please check the BTS before creating a new issue!
This is already reported as #914175.


Believe it or not I did but failed to notice.

-- eric

Bug#910902: akonadi-server: [alison@hildesheim A1Examen]$ akonadictl start

[Alison Chaiken]

Package: akonadi-server
Followup-For: Bug #910902

 Dear Maintainer,

   * What led up to the situation?

Never used Akonadi before.

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

Tried to run kAddressManager and 'akonadictl start'.

   * What was the outcome of this action?

GUI:
"The Akonadi personal information management service is not
operational."

CLI:
$ akonadictl start
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
$ akonadi.collectionattributetable   OK
akonadi.collectionmimetyperelation OK
akonadi.collectionpimitemrelation  OK
akonadi.collectiontableOK
akonadi.flagtable  OK
akonadi.mimetypetable  OK
akonadi.parttable  OK
akonadi.parttypetable  OK
akonadi.pimitemflagrelationOK
akonadi.pimitemtable   OK
akonadi.pimitemtagrelation OK
akonadi.relationtable
Error: Table 'akonadi.relationtable' doesn't exist in engine
status   : Operation failed
akonadi.relationtypetable
Error: Table 'akonadi.relationtypetable' doesn't exist in engine
status   : Operation failed
akonadi.resourcetable  OK
akonadi.schemaversiontable OK
akonadi.tagattributetable  OK
akonadi.tagremoteidresourcerelationtable   OK
akonadi.tagtable   OK
akonadi.tagtypetable   OK

Repairing tables
akonadi.relationtable
Error: Table 'akonadi.relationtable' doesn't exist in engine
status   : Operation failed
akonadi.relationtypetable
Error: Table 'akonadi.relationtypetable' doesn't exist in engine
status   : Operation failed
org.kde.pim.akonadiserver: "\nSql error: Duplicate entry 'PLAIN' for key 
'name' QMYSQL: Unable to execute query\nQuery: INSERT INTO TagTypeTable (name) 
VALUES ('PLAIN')"
org.kde.pim.akonadiserver: Unable to initialize database.

$ org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally.

   * What outcome did you expect instead?

Wanted to try kAddressManager for the first time.

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

Kernel: Linux 4.13.13 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages akonadi-server depends on:
ii  akonadi-backend-mysql  4:18.08.1-1
ii  libc6  2.27-8
ii  libgcc11:8.2.0-9
ii  libkf5akonadiprivate5abi2  4:18.08.1-1+b1
ii  libkf5akonadiwidgets5abi1  4:18.08.1-1+b1
ii  libkf5configcore5  5.49.0-1
ii  libkf5coreaddons5  5.49.0-1
ii  libkf5crash5   5.49.0-1
ii  libkf5i18n55.49.0-1
ii  libqt5core5a   5.11.2+dfsg-4
ii  libqt5dbus55.11.2+dfsg-4
ii  libqt5gui5 5.11.2+dfsg-4
ii  libqt5network5 5.11.2+dfsg-4
ii  libqt5sql5 5.11.2+dfsg-4
ii  libqt5widgets5 5.11.2+dfsg-4
ii  libqt5xml5 5.11.2+dfsg-4
ii  libstdc++6 8.2.0-9

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:18.08.1-1
pn  akonadi-backend-postgresql  
pn  akonadi-backend-sqlite  

-- no debconf information

Bug#914561: RFS: lebiniou-data/3.28-1 -- datafiles for Le Biniou

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

 * Package name: lebiniou-data
   Version : 3.28-1
   Upstream Author : Olivier Girondel 
 * URL : https://biniou.net
 * License : GPL-2+
   Section : graphics

It builds those binary packages:

lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

  https://mentors.debian.net/package/lebiniou-data


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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.28-1.dsc

Changes since the last upload:

  * New upstream release 3.28.
  * debian/tests/control: Depends: lebiniou (>= 3.28).

Regards,
  Olivier Girondel

Bug#914560: RFS: lebiniou/3.28-1 -- displays images that evolve with sound

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou":

 * Package name: lebiniou
   Version : 3.28-1
   Upstream Author : Olivier Girondel 
 * URL : https://biniou.net
 * License : GPL-2+
   Section : graphics

It builds those binary packages:

  lebiniou - displays images that evolve with sound

The package appears to be lintian-clean.

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.28-1.dsc

Changes since the last upload:

  * New upstream release 3.28.
  * configure.ac: armhf fixes.
  * configure.ac: Possible fix for a FTBFS on ia64.

Regards,
  Olivier Girondel

Bug#913548: spamassassin: running /etc/cron.daily/spamassassin gives: Unescaped left brace in regex is deprecated here

[Noah Meyerhans]

Control: tags -1 + moreinfo

On Mon, Nov 12, 2018 at 09:05:01AM +0100, Elimar Riesebieter wrote:
> 
> running /etc/cron.daily/spamassassin gives:
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
> 5.32), passed through in regex; marked by <-- HERE in m/ ( {<-- HERE } (?: / 
> \* )? | \* ) / at (eval 109) line 830.
> 

I'm not seeing this with 3.4.2-1 and perl 5.28.0-4. This was a known
upstream issue (https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7404)
and should be fixed in 3.4.2.

It seems that there are two possibilities:

1. The upstream fix was incomplete.

2. There are some spamassassin components on your system from outside
the packaging system.

Can you confirm that you're running /usr/bin/sa-update and that there
aren't any other copies of that program that could be getting picked up
by the cron job?

Unfortunately the message shown doesn't give a indication of exactly
where the problematic regex is, so I'll likely need some more info from
you to identify the source. Can you confirm that it's the sa-update
invocation that's actually triggering the warning?

Invoking sa-update as follows (as root) may provide some additional
detail:

# start-stop-daemon --chuid debian-spamd:debian-spamd --start --exec 
/usr/bin/sa-update -- --gpghomedir /var/lib/spamassassin/sa-update-keys -v -D

Thanks
noah



signature.asc
Description: PGP signature

Bug#914559: slepc: hardcodes path to sh depending on build host

[Paul Gevers]

Package: slepc
Version: 3.9.2+dfsg1-2

Dear maintainer,

Recently your package was rebuild as part of the hdf5 transition. During
the rebuild, the buildds accidentally had a merged usr setup [1].
Although this setup has been reverted, it exposed the fact that your
package embeds the path to sh from the build host, as the autopkgtest of
your started failing [2] with the error copied below. There was a large
thread on debian-devel@l.d.o about merged usr setup due to the buildd
issue. I think your build should not rely on the location of sh in the
$PATH of the build host.

I have requested binNMUs of your package on #debian-release.

Paul

[1] https://wiki.debian.org/UsrMerge
[2] https://ci.debian.net/packages/s/slepc/testing/amd64/
[3]
https://lists.debian.org/msgid-search/20181120211617.gxnuwxpx2hy44...@angband.pl

https://ci.debian.net/data/autopkgtest/testing/amd64/s/slepc/1370703/log.gz

autopkgtest [06:42:36]: test test-slepc: [---
make: /usr/bin/sh: Command not found
make: [makefile:140: test] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:84: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:85: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:86: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:87: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:88: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:89: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:90: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:91: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:92: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:93: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:94: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:95: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:96: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:97: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:98: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:99: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:100: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:101: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:102: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:103: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:104: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:105: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:106: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:107: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:108: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:109: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:110: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:111: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:112: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:113: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:114: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:115: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:116: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:117: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:157: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:158: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:159: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:160: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:161: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:162: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:163: testexamples] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:84: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:85: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:86: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:87: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: [makefile:88: info] Error 127 (ignored)
make: /usr/bin/sh: Command not found
make: 

Bug#907256: mkdocs: Remaining work items for version 1.0.x in unstable

[Jonas Smedegaard]

Package: mkdocs
Version: 1.0.2+dfsg-1
Followup-For: Bug #907256

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

lunr has now been packaged: Bug#914555.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlv5zPcACgkQLHwxRsGg
ASHWuw/+I+HYvxRioAXy/zGGrA7HDPOyGIe90/RyhtV+CNFelxszSMsHW0wPldww
ZFsylVVKvfpPKEeOQ/LfFKv9qSZDe1OQLWmUuAEAAF4a8SrikaJ3snRCboDs6lWT
G5jgrlNCp9FJEYwaaHxmaIDncrIWqKU/grPxbLwXBkrRprUS5qqkpuKLxgLg88eO
w/miZXWmFr6dVmpcp1B9pzbhWtB/vWq7YG3+HPrAAHQFlZuY6EB84jMz6HI0HDch
sluOArGMOU7qxyr8HxUqBm+mtocXQcvzVJKwZ8vHUdHgENxxgyL/nihSKPgmSQUv
kudLy4Bca1J0BzPpcuPanDv3FAkP+xWvyrpZaNEFXzWb4URZeBNmaEBoucbWRzHs
21kPKynW1R+Te1sfik2uukAQstPinY4WWdGkm4y7irdSevf6xIWsvvZ8HJxfQWVv
85qGrvvGhH93um3v61mkJj1ttNlBp0jtMSi8jGM23bp46XtHRtwoTM/ZhhCalH3/
NDkbagsPgXZKMLdDwheCUmbIf65Aw1mI31fbNID7QVSV/Scnsnoo0P0QiRxcXme0
GbqxfeiGpFyoSSmgZ05mKaaPE5icZa+u2L89Mm09dhoSBfI84LDTUUOr2w7/QZHn
wpKmvIpKQOooJMVAvy0dGMF0UNzNwn3s7txewSCQwQAT3XzCfNg=
=TqT8
-END PGP SIGNATURE-

Bug#914558: petsc: hardcodes path to sh depending on build host

[Paul Gevers]

Package: petsc
Version: 3.9.4+dfsg1-2

Dear maintainer,

Recently your package was rebuild as part of the hdf5 transition. During
the rebuild, the buildds accidentally had a merged usr setup [1].
Although this setup has been reverted, it exposed the fact that your
package embeds the path to sh from the build host, as the autopkgtest of
your started failing [2] with the error copied below. There was a large
thread on debian-devel@l.d.o about merged usr setup due to the buildd
issue. I think your build should not rely on the location of sh in the
$PATH of the build host.

I have requested binNMUs of your package on #debian-release.

Paul

[1] https://wiki.debian.org/UsrMerge
[2] https://ci.debian.net/packages/p/petsc/unstable/amd64/
[3]
https://lists.debian.org/msgid-search/20181120211617.gxnuwxpx2hy44...@angband.pl

https://ci.debian.net/data/autopkgtest/testing/amd64/p/petsc/1370827/log.gz

autopkgtest [07:28:26]: test test-petsc: [---
Running test examples to verify correct installation
Using PETSC_DIR=/usr/lib/petsc
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:158: clean-legacy] Error 127
(ignored)
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:159: clean-legacy] Error 127
(ignored)
run SNES testex19
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:402: ex19.PETSc] Error 127
(ignored)
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:403: ex19.PETSc] Error 127
(ignored)
make: /usr/bin/sh: Command not found
make: [makefile:266: testex19] Error 127 (ignored)
test HYPRE
make: /usr/bin/sh: Command not found
make: [makefile:287: runex19_hypre] Error 127 (ignored)
test MUMPS
make: /usr/bin/sh: Command not found
make: [makefile:297: runex19_fieldsplit_mumps] Error 127 (ignored)
run testex5f
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:453: ex5f.PETSc] Error 127
(ignored)
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:454: ex5f.PETSc] Error 127
(ignored)
make: /usr/bin/sh: Command not found
make: *** [makefile:250: testex5f] Error 127
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:158: clean-legacy] Error 127
(ignored)
make: /usr/bin/sh: Command not found
make: [/usr/lib/petsc/lib/petsc/conf/rules:159: clean-legacy] Error 127
(ignored)
Completed test examples
autopkgtest [07:28:26]: test test-petsc: ---]




signature.asc
Description: OpenPGP digital signature

Bug#870836: imake generated makefile use deprecated -D_BSD_SOURCE and -D_SVID_SOURCE

[Bart Massey]

Hilariously, I just ran into this today when building a program I wrote in
1987. Thanks huge to Teemu for working out the patch; I have verified that
it works for me. It would be great if this could be packaged.

Bug#914557: thunderbird: Version 1:60.3.0-1+b1 is not installable (breaks lightning and various calendar)

[Eric Valette]

Package: thunderbird
Version: 1:60.3.0-1+b1
Severity: important

LANG=C apt-get -s install thunderbird
NOTE: This is only a simulation!
  apt-get needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Recommended packages:
  lightning
The following packages will be REMOVED:
  calendar-exchange-provider calendar-google-provider lightning
The following packages will be upgraded:
  thunderbird
1 upgraded, 0 newly installed, 3 to remove and 5 not upgraded.
Remv calendar-exchange-provider [5.0.0~alpha1-1]
Remv calendar-google-provider [1:60.3.0-1]
Remv lightning [1:60.3.0-1]
Inst thunderbird [1:60.3.0-1] (1:60.3.0-1+b1 Debian:unstable [amd64])
Conf thunderbird (1:60.3.0-1+b1 Debian:unstable [amd64])

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-1
ii  libc6 2.28-0experimental1
ii  libcairo-gobject2 1.16.0-1
ii  libcairo2 1.16.0-1
ii  libdbus-1-3   1.13.6-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.2.0-10
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libglib2.0-0  2.58.1-6
ii  libgtk-3-03.24.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-2
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.39-1
ii  libpango-1.0-01.42.4-4
ii  libpangocairo-1.0-0   1.42.4-4
ii  libpangoft2-1.0-0 1.42.4-4
ii  libsqlite3-0  3.25.3-2
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-10
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-1
ii  libxcb1   1.13.1-1
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.3-1
ii  lightning1:60.3.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.1-3+b1
ii  fonts-lyx 2.3.1-2-2
ii  libgssapi-krb5-2  1.16.1-1

-- no debconf information

Bug#914556: linux: FTBFS on arm64: changed ABI

[Salvatore Bonaccorso]

Source: linux
Version: 4.9.135-1
Severity: serious
Justification: FTBFS
Control: affects -1 release.debian.org

For tracking the issue:

4.9.135-1 FTBFS on arm64 due to changed ABI:

https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=4.9.135-1=1543036173=0

Relevant part:

hnae_ae_register module: 
drivers/net/ethernet/hisilicon/hns/hnae, version: 0xdf635812 -> 0xbdde09c7, 
export: EXPORT_SYMBOL
hnae_ae_unregister   module: 
drivers/net/ethernet/hisilicon/hns/hnae, version: 0xe679c9fd -> 0x1c9eb41e, 
export: EXPORT_SYMBOL
hnae_get_handle  module: 
drivers/net/ethernet/hisilicon/hns/hnae, version: 0xafb4a8fd -> 0x29ae7935, 
export: EXPORT_SYMBOL
hnae_put_handle  module: 
drivers/net/ethernet/hisilicon/hns/hnae, version: 0x899f69bb -> 0x43a26da5, 
export: EXPORT_SYMBOL
hnae_reinit_handle   module: 
drivers/net/ethernet/hisilicon/hns/hnae, version: 0x767c1c31 -> 0xbc41182f, 
export: EXPORT_SYMBOL

Regards,
Salvatore

Bug#914555: ITP: node-lunr -- simple full-text search

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-lunr
  Version : 2.3.5
  Upstream Author : Oliver Nightingale 
* URL : https://lunrjs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : simple full-text search

 Lunr.js is a small, full-text search library for use in the browser.
 It indexes JSON documents and provides a simple search interface
 for retrieving documents that best match text queries.
 Async is a utility module which provides straight-forward, powerful
 functions for working with asynchronous Javascript.
 .
 This package provides Lunr for use directly in web browsers.

This package is needed by recent releases of mkdocs (see bug#907256).

The package will be maintained in the JavaScript team.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlv5xF0ACgkQLHwxRsGg
ASE5kA/+MMuMsObJdO6CctkzN3qh4tpQYWAk4Z3tRGfoiC6rNHIsZI9fxHEncTcf
n+r7CchTiG9XiZvUftG+TCZ/9Sy34oQ+x1RbfZbO9dU5bX1tandNXvwtyJ2IN27V
RQi91gN22gvZ0qbeozYDHcLJoe2EoYfVlGe6bkE3mqgHZjW/iwztoRP2OPgLHXnl
C8MYAhhHi0zRVdSAMcTmY28TPRyb/nHBFup7J47bpd8F6V/p2Py7KgOcFHPbmZvN
5hRo0kX8uebpgRLp9gHrXR7aQzKKIu8es9OVv6SX2h5D78cnSJoznw4NXB0DRJ5A
CdtimHlpxheTJzIsMUAxyn5qZyacEsjFAjNMiOdfp4wm7JkRk8VyXFACF8zHheke
8XztQ87GIPoXup8Ifj+rhEZVUZVelVDyztdyfgEfRiAcGQlU0gHbXKOT1C7VqyQy
GEnqa7g61mZFrAwdrp+BJX/nlJxI50iFK+hBwjK9XDTvuNuXRoDYtoHtcMxgm41E
BR5UdKnOfFqP70R97zZ397V10UF8KU65fpXxDpUXsqWAPhIOAnjcH7JaQu/v3f4d
p81K+XHO0l+OS+VFCqTZ8zyGlOmmQ5lHsSPUjj3oVToXG1/VbG9Xm64wbTfTOW8q
qvuSbDxN1TtEODdBiyNWCGiTAaO79vRFRXvT6+DUx+gRhOMW7xc=
=f0Xz
-END PGP SIGNATURE-

Bug#914554: clxclient FTBFS: freetype-config not found

[Mattia Rizzolo]

On Sat, Nov 24, 2018 at 09:43:31PM +0100, Helmut Grohne wrote:
> Source: clxclient
> Version: 3.9.0-4
> Severity: serious
> Tags: ftbfs patch upstream
> 
> clxclient fails to build from source in unstable, because
> freetype-config got removed. You're supposed to use pkg-config instead.
> The attached patch fixes the build.

That's despite the package not build-dependending on freetype nor any
binary having a dependency on it.
That's wrong on several levels, so please investigate why is it so, I'd
expect both a build-dep and a runtime dependency.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914554: clxclient FTBFS: freetype-config not found

[Helmut Grohne]

Source: clxclient
Version: 3.9.0-4
Severity: serious
Tags: ftbfs patch upstream

clxclient fails to build from source in unstable, because
freetype-config got removed. You're supposed to use pkg-config instead.
The attached patch fixes the build.

Helmut
--- clxclient-3.9.0.orig/Makefile
+++ clxclient-3.9.0/Makefile
@@ -31,8 +31,9 @@
 VERSION = $(MAJVERS).$(MINVERS)
 
 
-CPPFLAGS += -Wall -I. -I/usr/X11R6/include `freetype-config --cflags` -fpic -DVERSION=\"$(VERSION)\" -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -O2 
-LDFLAGS += -L/usr/X11R6/$(LIBDIR) -Wl,--as-needed `freetype-config --libs`
+PKG_CONFIG ?= pkg-config
+CPPFLAGS += -Wall -I. -I/usr/X11R6/include `$(PKG_CONFIG) freetype2 --cflags` -fpic -DVERSION=\"$(VERSION)\" -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -O2 
+LDFLAGS += -L/usr/X11R6/$(LIBDIR) -Wl,--as-needed `$(PKG_CONFIG) freetype2 --libs`
 LDLIBS +=
 
 

Bug#904309: RFP: tilda -- [SHORT DESCRIPTION]

[Pedro Ângelo]

I can confirm this issue (Segfault when trying to start under Wayland) is valid
in Debian Testing. 

The issue is known upstream (https://github.com/lanoxx/tilda/issues/314) 
andthere's a workaround in commit daa64f5. 

I tried cherry-picking this commit and installing the rebuilt Debian package,
and found that tilda starts up normally again.

Best regards,
P.

Bug#914553: sysstat: CVE-2018-19517: out of bound read in sadf which leads to crash

[Salvatore Bonaccorso]

Source: sysstat
Version: 12.0.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/sysstat/sysstat/issues/199

Hi,

The following vulnerability was published for sysstat, similar to
CVE-2018-19416.

CVE-2018-19517[0]:
| An issue was discovered in sysstat 12.1.1. The remap_struct function in
| sa_common.c has an out-of-bounds read during a memset call, as
| demonstrated by sadf.

The poc to verify a fix (base64 encoded here):

ltV1ITAwMDBIAQAAMDAwMAEBMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBQAAADAwMDkA
AAACAAAkEDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDABMDAwMAIBAAgwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAEBABAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMAAwMDAwMDAwMDAwMDAwMDAwMDAwMDAGiwEBACgA
AAAF/wAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAwMDAwMDAw
MDAwMDAwMDAwADAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=

This is similar to #914384 but fo the issue triggered during the memset call.

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-2018-19517
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19517

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#914552: black: FTBFS Attempt to download test dependencies during build

[Hans Joachim Desserud]

Source: black
Version: 18.9b0-1-5
Severity: serious
Tags: patch

Dear Maintainer,

I tried to build the package locally in pbuilder,
but it fails to build from source with the following error message:
running test
Searching for toml>=0.9.4

Note: Bypassing https://pypi.org/simple/toml/ (disallowed host; see 
http://bit.ly/2hrImnY for details).


Couldn't find index page for 'toml' (maybe misspelled?)
Scanning index of all packages (this may take a while)

Note: Bypassing https://pypi.org/simple/ (disallowed host; see 
http://bit.ly/2hrImnY for details).


No local packages or working download links found for toml>=0.9.4
error: Could not find suitable distribution for 
Requirement.parse('toml>=0.9.4')
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: 
python3.7 setup.py test



It fails since it attempts to download additional dependencies from the 
Internet.
I originally saw this when it failed to build when it was synced to 
Ubuntu [1][2],

but was also able to reproduce it on Sid.

With the attached patch, gradually adding additional build dependencies,
it eventually built successfully.

[1] 
https://launchpad.net/ubuntu/+source/black/18.9b0-1-5/+build/15638431
[2] 
https://launchpadlibrarian.net/39789/buildlog_ubuntu-disco-amd64.black_18.9b0-1-5_BUILDING.txt.gz


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index 4bca183..bcd8447 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,8 @@ Maintainer: Neil Williams 
 Build-Depends: debhelper (>= 11), dh-python,
  python3, python3-recommonmark, python3-setuptools,
  python3-sphinx, python3-docutils,
- libjs-underscore, libjs-jquery
+ libjs-underscore, libjs-jquery,
+ python3-appdirs, python3-attr, python3-click, python3-toml
 Standards-Version: 4.2.1
 Homepage: https://github.com/ambv/black
 X-Python3-Version: >= 3.6

Bug#914551: tootle: segfaults in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0

[Jeff Cliff]

Package: tootle
Version: 0.2.0-1
Severity: normal

Dear Maintainer,

after having being running all night and exhibiting bug #911075 and then having 
a manual refresh (user icon->refresh)
tootle segfaulted.

#0  0x7f3b48d999f5 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7f3b48d9ad0d in g_logv () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f3b48d9aedf in g_log () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f3b48fc1f78 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x7f3b48e79749 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7f3b48e7b224 in g_object_new_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7f3b48e7b559 in g_object_new () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7f3b48a167e0 in  () at /usr/lib/x86_64-linux-gnu/libgranite.so.5
#8  0x7f3b48a16a5c in granite_date_time_get_relative_datetime () at 
/usr/lib/x86_64-linux-gnu/libgranite.so.5
#9  0x55e3d8beb518 in tootle_status_widget_rebind 
(self=self@entry=0x55e3dc2da990) at ../../src/Widgets/StatusWidget.vala:218
#10 0x55e3d8bebae1 in tootle_status_widget_construct 
(object_type=, status=status@entry=Python Exception  Variable 'static_fundamental_type_nodes' not found.: 
) at ../../src/Widgets/StatusWidget.vala:196
#11 0x55e3d8bec005 in tootle_status_widget_new (status=status@entry=Python 
Exception  Variable 'static_fundamental_type_nodes' not 
found.: 
) at ../../src/Widgets/StatusWidget.vala:125
#12 0x55e3d8bf53dc in tootle_timeline_view_append (self=0x55e3da4a24a0, 
status=Python Exception  Variable 
'static_fundamental_type_nodes' not found.: 
, first=0) at ../../src/Views/TimelineView.vala:58
#13 0x55e3d8bf55f6 in ___lambda54_ (i=, node=, array=, self=0x55e3da4a24a0) at 
../../src/Views/TimelineView.vala:124
#14 0x55e3d8bf55f6 in lambda54__json_array_foreach (array=, index_=, element_node=, self=0x55e3da4a24a0)
at ../../src/Views/TimelineView.vala:120
#15 0x7f3b489d5096 in json_array_foreach_element () at 
/usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0
#16 0x55e3d8bf59fa in __lambda53_ (mess=0x55e3dc047d90, sess=, self=0x55e3da4a24a0) at ../../src/Views/TimelineView.vala:120
#17 0x55e3d8bf59fa in ___lambda53__soup_session_callback 
(session=, msg=0x55e3dc047d90, self=0x55e3da4a24a0) at 
../../src/Views/TimelineView.vala:118
#18 0x55e3d8bdd994 in __lambda116_ (mess=0x55e3dc047d90, 
sess=0x55e3da17b100, _data7_=0x55e3db7ca6d0) at ../../src/Network.vala:71
#19 0x55e3d8bdd994 in ___lambda116__soup_session_callback 
(session=0x55e3da17b100, msg=0x55e3dc047d90, self=0x55e3db7ca6d0) at 
../../src/Network.vala:47
#20 0x7f3b4898ecde in  () at /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#21 0x7f3b4898f6ca in  () at /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#22 0x7f3b4898f756 in  () at /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1
#23 0x7f3b48d93ae8 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x7f3b48d93ed8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x7f3b48d93f6c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x7f3b48f5a13d in g_application_run () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#27 0x55e3d8bd6639 in tootle_application_main (args=, 
args_length1=) at ../../src/Application.vala:56
#28 0x7f3b487a0b17 in __libc_start_main (main=
0x55e3d8bd5c60 , argc=1, argv=0x7ffe420964b8, init=, 
fini=, rtld_fini=, stack_end=0x7ffe420964a8)
at ../csu/libc-start.c:310
#29 0x55e3d8bd5c9a in _start () at ../../src/Application.vala:43

[Switching to thread 2 (Thread 0x7f3b315bf700 (LWP 569))]
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38  ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt
#0  0x7f3b48870a79 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f3b48dda75a in g_cond_wait_until () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f3b48d66061 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f3b48dbcc12 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f3b48dbc135 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f3b474f7f2a in start_thread (arg=0x7f3b315bf700) at 
pthread_create.c:463
#6  0x7f3b48875edf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 3 
[Switching to thread 3 (Thread 0x7f3b41bf3700 (LWP 30717))]
#0  0x7f3b4886b739 in __GI___poll (fds=0x55e3d9fced10, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0  0x7f3b4886b739 in __GI___poll (fds=0x55e3d9fced10, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f3b48d93e46 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f3b48d93f6c in g_main_context_iteration () at 

Bug#914384: sysstat: CVE-2018-19416: the remap_struct function in sa_common.c has an out-of-bounds read during a memmove call

[Markus Koschany]

Hi,

On Thu, 22 Nov 2018 21:35:39 +0100 Salvatore Bonaccorso
 wrote:
> Source: sysstat
> Version: 12.0.1-1
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/sysstat/sysstat/issues/196
> 
> Hi,
> 
> The following vulnerability was published for sysstat.
[...]

I can't reproduce the issue on Jessie. By executing the POC with sadf
stack_oob I get

Invalid system activity file: stack_oob
File created by sar/sadc from sysstat version 48.48.48.48
Current sysstat version can no longer read the format of this file (0x2175)

Looking closer at the affected source code I see that the vulnerable
function remap_struct was first introduced on 22.9.2017.

https://github.com/sysstat/sysstat/commit/65ac30359e49ee717397e39950d7c24a6610d57c#diff-cccb0877d1539c562536a98e0d17428f

Hence I think Jessie is not affected. If I am correct then Stretch
should be safe as well, double-checking that would be appreciated.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#914547: Same issue here

[aruhuno]

Hello,

I've the same issue:

aruhuno@mufasa:~$ sudo apt install virtualbox
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :

Les paquets suivants contiennent des dépendances non satisfaites :
 virtualbox : Dépend: python3 (< 3.7) mais 3.7.1-2 devra être installé
  Recommande: virtualbox-qt (= 5.2.22-dfsg-1) mais ne sera pas
installé
  Recommande: libqt5opengl5 (>= 5.0.2) mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en
mode « garder en l'état ».
aruhuno@mufasa:~$ apt policy python3
python3:
  Installé : 3.7.1-2
  Candidat : 3.7.1-2
 Table de version :
 *** 3.7.1-2 500
500 http://ftp.fr.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
aruhuno@mufasa:~$ cat /etc/debian_version
buster/sid

Thanks for your work!

Bug#914550: borgbackup needs to be rebuilt for python 3.7

[Albert Dengg]

Package: borgbackup
Version: 1.1.7-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

since the update to python 3.7 in debian unstable, borg is uninstable.

a simple rebuild of the package seems to be enough to get a working
package.

regards,
albert dengg


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

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

Versions of packages borgbackup depends on:
ii  fuse   2.9.8-2
ii  libacl12.2.52-3+b1
ii  libb2-10.98-1
ii  libc6  2.27-8
ii  liblz4-1   1.8.2-1
ii  libssl1.1  1.1.1-2
ii  libzstd1   1.3.5+dfsg-1
ii  python33.7.1-2
ii  python3-llfuse 1.3.5+dfsg-1
ii  python3-msgpack0.5.6-1+b1
ii  python3-pkg-resources  40.5.0-1

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

Bug#914549: Segmentation fault for some videos (assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed)

[antistress]

Package: gstreamer1.0-plugins-base
Version: 1.14.4-dmo1

Hi,

When I try to open some videos, totem crashes at startup.

Here is an exemple of message I got :
"(totem:4264): GStreamer-CRITICAL **: 18:59:54.407: 
gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' 
failed

Erreur de segmentation"

And if I try to display Nautilus video properties panel for this file, I 
also get a crash, with Nautilus :
"(nautilus:4922): GStreamer-CRITICAL **: 19:18:32.282: 
gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' 
failed

Erreur de segmentation"

Reading the file with VLC is OK.
From VLC I get this video file properties : Xvid MPEG-4 VIDEO & MPEG 
Audio layer 3. And it's an AVI file.


Notice that :
- some other Xvid MPEG-4 VIDEO & MPEG Audio layer 3 & AVI file work fine.
- files that don't work have this particularity that can be seen from 
VLC codecs panel : video resolution and buffer dimension are not the 
same (i.e. 720x404 & 720x416, or 624x300 & 624x320).


I have this bug for some months now, and it's still there and I can't 
find any related bug, therefore here's my report.


Thanks !

---

Here is my configuration :

* Software :
Linux HAL 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 
GNU/Linux

libc6 2.27-8
totem 3.26.2-1
nautilus 3.30.3-1
gstreamer1.0-plugins-bad 1:1.14.4-dmo2
gstreamer1.0-plugins-good 1.14.4-dmo1
gstreamer1.0-plugins-ugly 1:1.14.4-dmo1

* Hardware
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 
v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)

Subsystem: ASRock Incorporation Motherboard [1849:0162]
Kernel driver in use: i915

Bug#888479: tcsh 6.20.00-7 crashes when entering non-ascii characters

[Thomas Lange]

Yes a proper diff or patch file would be great.
-- 
regards Thomas

Bug#551707: Processed: Re: dlocate does not complete filenames

[Gabriel F. T. Gomes]

On Sun, 27 Dec 2009 23:35:15 +0100 David Paleino  wrote:
> On Sunday 27 December 2009 23:27:33, Craig Sanders wrote:
> > how should we handle this? should I release a new dlocate without
> > completion first, or will you divert the completion file to your
> > package?
> 
> It would be best if you released a dlocate without completion, and next I 
> release a package Conflicting with dlocate (<< new_version).
> I think that's sufficient. Any other idea?

Hi, Craig,

Are you still willing to move the completion file for dlocate from the
dlocate package to bash-completion (upstream and downstream)?

If so, I'll prepare a patch for upstream bash-completion, as well as an
upload for downstream bash-completion and wait for your upload removing
it from dlocate.

> For the upstream team: the conflict is obviously only related to the Debian 
> package, to avoid file conflicts on installation.

This conflict is not really necessary anymore, because completion files
are now installed under /usr/share/bash-completion/completions, and
dlocate still uses the obsolete dir, i.e.: /etc/bash_completion.d/,
thus, there would be no installation conflicts.


Thanks,
Gabriel

Bug#861781: www.debian.org: updating Debian memberships in other organisations information

[Molly de Blanc]

Debian is also an affiliate member of the Open Source Initiative.

I removed Desktop Linux Consortium and added the OSI to the membership
page: https://salsa.debian.org/webmaster-team/webwml/merge_requests/44

Cheers,
Molly

Bug#913287: Bug#912925: Is the SONAME the same for all the related libs?

[Julian Gilbey]

On Fri, Nov 23, 2018 at 10:07:47AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi Julian!
> 
> El jueves, 22 de noviembre de 2018 21:54:30 -03 Julian Gilbey escribió:
> > On Sun, Nov 18, 2018 at 03:35:11PM +, Julian Gilbey wrote:
> > > On Sun, Nov 18, 2018 at 09:01:19AM -0300, Lisandro Damián Nicanor Pérez 
> Meyer wrote:
> > > > Yesterday I've uploaded qtbase with this fix, please try it.
> > > 
> > > Excellent, thanks!  I just built it on my testing machine, and it
> > > worked perfectly with the Python script in this bug report and the
> > > simplebrowser example.
> > 
> > Hi Lisandro,
> > 
> > Upstream have now patched what-I-presume-will-become 5.12.1 with
> > almost this patch.  But it's gone through several iterations, and now
> > the patch also deletes a couple of #include's.  See patch set #7 at
> > https://codereview.qt-project.org/#/c/245294/
> > 
> > I doubt it's worth uploading a new version just for this, but when you
> > are doing the next qtbase upload, you might consider making this
> > change.
> 
> That's exactly the patch with which I closed this bug. This is already in the 
> archive. Enjoy!

Hi Lisandro,

Version 7 of the patch is slightly different from the one you applied
to the archive: it also removes some conditional #includes. But it is
probably unimportant for Debian.

Best wishes,

   Julian

Bug#914547: virtualbox is not installable. Depends: python3 (< 3.7) but 3.7.1-2 is to be installed

[Robert Ulrich]

Package: virtualbox
Version: 5.2.20-dfsg-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

 Dist-upgrade on sid/unstable introduced an unmet python3 dependency. 
Virtualbox
 depends on version < 3.7 but python3 is currently installed with version 
3.7.1-2

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

 Performed a dist-upgrade on sid/unstable 

   * What was the outcome of this action?

 The package got removed due to the unmet dependency.

   * What outcome did you expect instead?

 Expected the package to be kept installed.

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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  4.18.0-2
ii  libc6 2.27-8
ii  libcurl3-gnutls   7.62.0-1
ii  libdevmapper1.02.12:1.02.145-4.1
ii  libgcc1   1:8.2.0-10
pn  libgsoap-2.8.60   
ii  libpng16-16   1.6.34-2
ii  libpython3.6  3.6.7-1
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libssl1.1 1.1.1a-1
ii  libstdc++68.2.0-10
pn  libvncserver1 
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.1.15-2
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-7+b2
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.15-2
ii  python3   3.7.1-2
ii  python3.6 3.6.7-1
ii  virtualbox-dkms [virtualbox-modules]  5.2.22-dfsg-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages virtualbox recommends:
ii  libgl1  1.1.0-1
ii  libqt5core5a5.11.2+dfsg-7
ii  libqt5opengl5   5.11.2+dfsg-7
ii  libqt5widgets5  5.11.2+dfsg-7
pn  virtualbox-qt   

Versions of packages virtualbox suggests:
pn  vde2
pn  virtualbox-guest-additions-iso  

Bug#614775: bash-completion: perl -d inhibits filename completion

[Gabriel F. T. Gomes]

On Sat, 24 Nov 2018 12:53:38 -0200 "Gabriel F. T. Gomes" 
 wrote:
>
> I'll apply it to Debian's bash-completion for the next upload.

Now in the git repository [1].  I'll wait for more changes (or more
time) before doing a new upload.

[1] 
https://salsa.debian.org/debian/bash-completion/commit/5506a39b0f16cee692f44c209a0d1a3b98fa969f

Bug#904009: closed by Sandro Tosi (Re: Bug#904009: reportbug: Backspace, arrow keys and more thing like ctrl+c are not working in some programs)

[Sandro Tosi]

On Sat, Nov 24, 2018 at 3:06 AM develo...@oldunreal.com
 wrote:
>
> I am sorry, I don't understand the explanation for closing this bug. It

reportbug is the tool Debian uses to report bugs. if you file a bug
against it, it means there is a bug in reportbug itself; it's not just
a generic placeholder to report bugs that are not trivial to pinpoint
to a specific issue.

> happens out of the box (fresh install) for various applications, on
> different machines without having any user modifications done. So I have
> to assume some more global issue.
> How can the average user be expected to dig out a solution for this or
> asking for it not having the slightest clue where it is coming from. It

if that's the case, reportbug is not the tool you should be using, but
instead you should seek advice on a user support forum, such as
https://lists.debian.org/debian-user/ ,as i pointed out when closing
the report. Please refer to that mailing list for further questions.


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

Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2

[Mattia Rizzolo]

On Sat, Nov 24, 2018 at 03:41:36PM +0100, Mattia Rizzolo wrote:
> > > Gert: you mention you gave up on symbols, but at least in gdcm's
> > > changelog I don't see anything about that.  Had you had troubles
> > > there as well?
> > TBH I never tried with gdcm, I think I started to upload the package
> > when it was already at version 2.4 and I didn't even note that there is
> > a script for the symbols there (which points at 2.2).
…
> At the same time, libvtkgdcm is much more tidy, so at least I will start
> adding a .symbols file to that one...

I've now uploaded a version to experimental with a .symbols file for
libvtkgdcm2.8 only, to check that the symbols don't vary further across
architectures…

The only differences I notice between amd64 and i386 are that some
vtk-related functions change from long long on amd64 to int in i386.


I pushed everything to git, including my proposal to rename the package
to a wip branch, which I'll upload tomorrow if the builds in
experimental are alright (hopefully I'll get some ftp-master to
fast-track it as well).

Gert: I notice several tags are missing in the gdcm repository, could
you push them?



> > > What I would welcome your help with is explaining the camitk FTBFS on
> > > i386.
> > Just had as peek, my guess is that this will help: 
> > 
> > ifeq ($(DEB_BUILD_ARCH),i386)
> 
> Note that here you probably meant DEB_HOST_ARCH, not build arch.
> 
> >   export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
> > endif
> > 
> > The same was needed for ITK because they write tests with floating
> > point values apparently comparing with high accuracy, and on i386
> > optimizations can lead to the used of intermediate 80 bit floating
> > point values that then result in test failures because the references
> > were tuned for 64 bit floating point values. Adding above flag makes
> > sure that intermediate results are not keps in these 80 bit FPU
> > registers.
> 
> ACK, thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914524: Quick-and-Dirty fix that makes the problem go away

[Nis Wechselberg]

Greetings,

to get our sogo running, and to verify that the gnutls/openssl issue is
in fact the main culprit, I did this quick-and-dirty workaround:

--- sogo-4.0.4.orig/UI/MailPartViewers/UIxMailPartSignedViewer.m
+++ sogo-4.0.4/UI/MailPartViewers/UIxMailPartSignedViewer.m
@@ -169,11 +169,12 @@
   if (err)
 {
 #ifdef HAVE_GNUTLS
-  const char* sslError;
- ERR_load_crypto_strings();
-  SSL_load_error_strings();
-  sslError = ERR_reason_error_string(err);
-  validationMessage = [[self labelForKey: [NSString
stringWithUTF8String: sslError ? sslError : @"No error information
available"]] retain];
+//  const char* sslError;
+//   ERR_load_crypto_strings();
+//  SSL_load_error_strings();
+//  sslError = ERR_reason_error_string(err);
+//  validationMessage = [[self labelForKey: [NSString
stringWithUTF8String: sslError ? sslError : @"No error information
available"]] retain];
+ validationMessage = [[self labelForKey: @"No error information
available"] retain];
 #elif OPENSSL_VERSION_NUMBER < 0x1010L
   const char* sslError;
  ERR_load_crypto_strings();

With this patch sogo starts again without errors and the mail ui loads.

Regards,
Nis Wechselberg



signature.asc
Description: OpenPGP digital signature

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

[Daniel Scharon]

Hi Martin,

On Fri, 23 Nov 2018 14:24:52 +0100 "W. Martin Borgert"  wrote:
> any progress in finding a new or the right upstream?

the more or less official looking successor repo on LuaRocks seems to be: 
https://luarocks.org/modules/devurandom/lualdap
Which points to: https://github.com/lualdap/lualdap

> The problem becomes a little bit more pressing now:
> I plan to upload prosody 0.11 to unstable soon, maybe today.
> Prosody 0.11 uses Lua 5.2 instead of 5.1 as recommended by upstream.

Prosody 0.11 seems to be the last version to still support Lua 5.1, so
using Lua 5.1 may seem like a workaround, at least for stretch-
backports?

Kind regards,
Dan


smime.p7s
Description: S/MIME cryptographic signature

Bug#901583: ITP: golang-github-danverbraganza-varcaser

[Tong Sun]

Alright. refreshing this old ITP as I'm ready to give it another try.

Bug#914546: ruby-oj FTBFS on 32bit: test failure

[Adrian Bunk]

Source: ruby-oj
Version: 3.7.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=ruby-oj=sid

...
┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rb  │
└──┘

RUBYLIB=/<>/debian/ruby-oj/usr/lib/i386-linux-gnu/ruby/vendor_ruby/2.5.0:/<>/debian/ruby-oj/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-oj/usr/share/rubygems-integration/2.5.0:/var/lib/gems/2.5.0:/usr/lib/i386-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
 ruby2.5 debian/ruby-tests.rb
 running test/tests.rb test --- 
Run options: --seed 12044

# Running:

.{}
E.

Finished in 0.091600s, 5098.2310 runs/s, 9530.5261 assertions/s.

  1) Error:
Juice#test_time_neg:
ArgumentError: time out of system range
/<>/test/test_various.rb:419:in `dump'
/<>/test/test_various.rb:419:in `test_time_neg'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:265:in `time_it'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:360:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:960:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:334:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:321:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:320:in `each'
/usr/lib/ruby/vendor_ruby/minitest.rb:320:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:360:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest.rb:347:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest.rb:319:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `block in __run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `map'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `__run'
/usr/lib/ruby/vendor_ruby/minitest.rb:136:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:63:in `block in autorun'

467 runs, 873 assertions, 0 failures, 1 errors, 0 skips
E: Test test/tests.rb has failed.
 running test/tests_mimic.rb test --- 
Loaded suite test/tests_mimic
Started
..O
===
Omission: mimic_JSON [test_deep_const_get(JSONCommonInterfaceTest)]
/<>/test/json_gem/json_common_interface_test.rb:55:in 
`test_deep_const_get'
===
...

Finished in 0.127731524 seconds.
---
82 tests, 1966 assertions, 0 failures, 0 errors, 0 pendings, 1 omissions, 0 
notifications
100% passed
---
641.97 tests/s, 15391.66 assertions/s
 running test/tests_mimic_addition.rb test --- 
Loaded suite test/tests_mimic_addition
Started
...
Finished in 0.004811668 seconds.
---
11 tests, 42 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 
notifications
100% passed
---
2286.11 tests/s, 8728.78 assertions/s
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-oj returned 
exit code 1
make: *** [debian/rules:15: binary-arch] Error 1

Bug#914545: sympow FTBFS: error: 'GP' undeclared

[Adrian Bunk]

Source: sympow
Version: 2.023.5-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=sympow=sid

...
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-unused-result -O3  -std=gnu17 -fno-fast-math 
-mfpmath=sse -ffp-contract=on -DFPUCONTROLH   -c -o generate.o generate.c
generate.c: In function 'new_data':
generate.c:234:32: error: 'GP' undeclared (first use in this function)
  execlp(SH,SH,newdatascript,SH,GP,ARGS,NULL);}
^~
generate.c:234:32: note: each undeclared identifier is reported only once for 
each function it appears in
make[1]: *** [Makefile:45: generate.o] Error 1

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

[John David Anglin]

On 2018-11-18 3:08 p.m., Michael Biebl wrote:

Unfortunately not. You could talk to Jussi Pakkanen, our meson
maintainer and upstream of meson, maybe he can help here.

I created two bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914543
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88185

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#914126: svtplay-dl: bugs out on urplay.se

[Cristian Ionescu-Idbohrn]

On Sat, 24 Nov 2018, Cristian Ionescu-Idbohrn wrote:
> On Fri, 23 Nov 2018, Olof Johansson wrote:
> > On 18-11-19 18:37 +0100, Cristian Ionescu-Idbohrn wrote:
> > > This is what I see:
> > ...
> > > requests.exceptions.SSLError: 
> > > HTTPSConnectionPool(host='streaming-loadbalancer.ur.se', port=443): Max 
> > > retries exceeded with url: /loadbalancer.json (Caused by 
> > > SSLError(SSLError("bad handshake: Error([('SSL routines', 
> > > 'ssl_choose_client_version', 'unsupported protocol')],)",),))
> > > 
> > > when trying to download:
> > > 
> > >   https://urplay.se/program/204949-roster-fran-australiens-aboriginer
> > > 
> > > for example.  Works fine when playing it in chromium, though.
> > > 
> > > Downloading from svtplay.se works fine, though.
> > 
> > Thanks for the report, I have been postponing upgrading to the
> > new 2.0+ version, but should get on that asap. Hopefully that
> > should solve it.
> 
> Doesn't seem so :(  I tested with master (2.1-14-g72143b7).  Similar 
> problem.  Attaching a trace done with that version.

FWIW, `curl' is showing a similar error when attempting to download:

$ curl -v https://streaming-loadbalancer.ur.se/loadbalancer.json
*   Trying 130.242.59.74...
* TCP_NODELAY set
* Connected to streaming-loadbalancer.ur.se (130.242.59.74) port 443 
(#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported 
protocol
* Closing connection 0
curl: (35) error:1425F102:SSL 
routines:ssl_choose_client_version:unsupported protocol

But `wget' manages to do it:

$ wget -O - --quiet 
https://streaming-loadbalancer.ur.se/loadbalancer.json;echo
{"geoip_country_code":"SE","redirect":"streaming4.ur.se"}

`svtplay-dl` 1.9.1-0.1 on stretch manages to download:

$ svtplay-dl --verbose -P hls -g 
https://urplay.se/program/204949-roster-fran-australiens-aboriginer 
DEBUG [1543070399.9] 
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting 
'https://urplay.se/program/204949-roster-fran-australiens-aboriginer'
DEBUG [1543070400.01] 
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting 
u'https://streaming-loadbalancer.ur.se/loadbalancer.json'
DEBUG [1543070400.11] 
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting 
u'http://streaming4.ur.se/urplay/_definst_/mp4:se/204000-204999/204949-11.mp4/playlist.m3u8'
DEBUG [1543070400.3] 
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting 
u'http://streaming4.ur.se/urplay/_definst_/mp4:se/204000-204999/204949-5.mp4/playlist.m3u8'
DEBUG [1543070400.72] 
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/protocol_prio: Protocol 
priority scores (higher is better): {'dash': 5, 'hds': 3, 'hls': 4, 'http': 2, 
'rtmp': 1}

https://streaming4.ur.se/urplay/_definst_/mp4:se/204000-204999/204949-5.mp4/chunklist_w64863179.m3u8

So, it seems the problem might very well be openssl both in buster and
sid, but I may be wrong.

On sid:

$ openssl s_client -connect streaming-loadbalancer.ur.se:443;echo $?
CONNECTED(0003)
140235689968640:error:1425F102:SSL 
routines:ssl_choose_client_version:unsupported 
protocol:../ssl/statem/statem_lib.c:1940:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 86 bytes and written 327 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

fails.  See Bug#912737 too.  But it succedes if I force TLS down to 
TLSv1:

$ openssl s_client -tls1 -connect streaming-loadbalancer.ur.se:443;echo 
$?  
CONNECTED(0003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert 
Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte 
RSA CA 2018
verify return:1
depth=0 C = SE, L = Stockholm, O = Sveriges Utbildningsradio AB, OU = 
IT, CN = *.ur.se
verify return:1
139650269000704:error:141A318A:SSL routines:tls_process_ske_dhe:dh key 
too small:../ssl/statem/statem_clnt.c:2160:
---
Certificate chain
 0 s:C = SE, L = Stockholm, O = Sveriges Utbildningsradio AB, OU = IT, 
CN = *.ur.se
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA 
CA 2018
 1 s:C = US, 

Bug#914544: xss-lock: Fails to run locker with -n and cycle time 0

[Teemu Ikonen]

Package: xss-lock
Version: 0.3.0-5
Severity: normal
Tags: upstream

When the X screensaver extension cycle time (as in 'xset s TIMEOUT
CYCLE') is set to 0 and xss-lock is run with a notification command (the
-n option), the locker command is not being run at all when timeout is
reached. This of course has some security implications.

This would perhaps not be a big problem, but xfce4-power-manager seems
to really want to set the screensaver cycle time to 0 on startup, or
whenever the 'Blank after' time is changed on the GUI.

I think the correct behaviour in the case of cycle time = 0 would be
to run the notification and locker commands one after the other.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages xss-lock depends on:
ii  libc62.24-11+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libxcb-screensaver0  1.12-1
ii  libxcb-util0 0.3.8-3+b2
ii  libxcb1  1.12-1

xss-lock recommends no packages.

xss-lock suggests no packages.

-- no debconf information

Bug#866653: RFS: thawab 4.1-1 [UPDATE]

[Jeremy Bicha]

Let me clarify:

You could upload thawab yourself today [1] as long as you make sure to
do a full source-and-binaries upload. You won't be able to do a
source-only upload until you get confirmation that autobuild has been
turned on for thawab.

I could upload othman today (it will need to go through the NEW queue)
but I prefer to wait until after you start the autobuild process. That
way, we will not have this issue again for othman.

[1] https://ftp-master.debian.org/dm.txt

Thanks,
Jeremy Bicha

Bug#914543: meson adds both -fPIE and -fPIC options in LTO compiles with gcc-8

[John David Anglin]

Source: meson
Severity: normal

Dear Maintainer,

The systemd package fails to build on hppa and x32.  This is caused by
both -fPIE and -fPIC options being added to various compilation commands.
Only -fPIC is being recorded in the LTO options section of the object.
The gcc-8 LTO plugin merges -fPIC + -fPIE to nothing.  So, the compilations
done by the plugin are not position-independent and fail to link with -pie.

I have not found a way to change the addition of these options within systemd.

My understanding is -fPIE should be used when creating objects for a
PIE executable.  -fPIC should be used when creating objects for a shared
library.  Only one is recorded when -flto is specified.

For more details, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88185

Regards,
Dave Anglin

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.81+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#914541: [libpam-modules-bin] unix_chkpwd should be SUID instead of SGID, otherwise kscreen_locker does not work

[hg42]

Package: libpam-modules-bin
Version: 1.1.8-3.8
Severity: important

--- Please enter the report below this line. ---

I ran into that quite a while ago, but wasn't using a screen locker or KDE 
since, so I forgot about it. Now, with KDE and mostly hibernating my system, it 
came back.


unix_chkpwd is installed SGID (2755) in all currently available 
libpam-modules-bin versions:

1.1.8-3.2ubuntu2
1.1.8-3.2ubuntu2.1
1.1.8-3.2ubuntu3
1.1.8-3.2ubuntu3.1
1.1.8-3.6
1.1.8-3.6ubuntu2
1.1.8-3.8

With these permissions correct passwords fail in newer KDE screen locker 
versions. I tested libkscreenlocker5 versions:

5.13.5-1
5.8.6-2
5.12.6-0ubuntu0.1
5.12.4-0ubuntu1

for a recent occurance of the issue see here:
https://www.reddit.com/r/kde/comments/8w7uqq/screen_wont_unlock/e1wbilp/?context=8=9

I found a discussion about SUID vs. SGID for unix_chkpwd here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155583

Note, I am not an expert in security related things, but the reasoning in the 
discussion doesn't look logical, so I'll try to explain my view as a user.


There probably was a reason why it was SUID before. Obviously nobody is talking 
about that decision.


The discussion about switching to SGID seems to be about explicit packages that 
fail and solutions for them.


But as I understand this, it doesn't say, there cannot be or can never be other 
packages that need unix_chkpwd to be SUID. May be, this is totally obvious to 
you and it doesn't need to be discussed. But at least the KDE screen locker is 
an example.

Also, bashing NIS doesn't help, especially if there could be other software.

So, one question is, why is SGID better than SUID? is it worth breaking packages 
if you don't know, why SUID was part of the design?
The other question is, why does another package need unix_chkpwd SUID? is it 
insecure or otherwise bad code in some way?


That said, the problem could also be in the code of the screen locker.


--- System information. ---
Architecture: Kernel:   Linux 4.18.0-2-amd64

Debian Release: buster/sid
  990 stable  security.debian.org   900 xenial-security 
archive.ubuntu.com   900 testing debian.netcologne.de   900 stable 
   kxstudio.linuxaudio.org   900 stable  dl.google.com   900 stable 
 debian.netcologne.de   900 bionic-security archive.ubuntu.com   900 
artful-security archive.ubuntu.com   500 xenial  ppa.launchpad.net   500 
wilyppa.launchpad.net   500 trusty  ppa.launchpad.net   500 
lucid   ppa.launchpad.net   500 gcc5kxstudio.linuxaudio.org 
 500 bionic  ppa.launchpad.net   500 artful  ppa.launchpad.net 
 100 xenial-updates  archive.ubuntu.com   100 xenial-backports 
archive.ubuntu.com   100 xenial  archive.ubuntu.com   100 unstable 
 packages.siduction.org   100 unstabledebian.netcologne.de   100 
experimentaldebian.netcologne.de   100 bionic-updates  archive.ubuntu.com 
100 bionic-backports archive.ubuntu.com   100 bionic  archive.ubuntu.com 
  100 artful-updates  archive.ubuntu.com   100 artful-backports 
archive.ubuntu.com   100 artful  archive.ubuntu.com

--- Package information. ---
Depends (Version) | Installed
=-+-==
libaudit1(>= 1:2.2.1) | 1:2.8.4-2
libc6   (>= 2.14) | libpam0g(>= 0.99.7.1) | libselinux1 
   (>= 1.32) |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#914542: dict-jargon: Merging with src:jargon and src:jargon-text

[Dmitry Bogatov]

Package: dict-jargon
Severity: wishlist

Dear Maintainer,

There is three source packages in Debian, that contain Jargon File

 * `dict-jargon' (v4.4.7)
 * `jargon-text' (v4.4.7) -- orphaned
 * `jargon' (v4.0.0) -- out-of-date, as written in description

Hereby I propose to combine functionality of those packages in single
source package, probably yours `dict-jargon', as most actively
maintained.

It would mean to

 * copy Makefile from `jargon-text' to generate HTML and plain text
   formats
 * apply patch for `jargon-text' to additionally generate fortunes file.
 * invent a way to convert source xml into GNU Info format, to
   supersede `jargon' package.

After that we could RM src:jargon-text and src:jargon. If you agree, I
volonteer to prepare patch.

Bug#914175: lightning is not installable after binNMUs

[Carsten Schoenert]

Control: tags -1 pending

Hello Adrian,

Am 20.11.18 um 08:52 schrieb Adrian Bunk:
> Package: lightning
> Version: 1:60.3.0-1
> Severity: serious
> 
>  thunderbird : Breaks: lightning (< 1:60.3.0-1+b1) but 1:60.3.0-1 is to be 
> installed
> 
> lightning is binary-all, ${source:Version} should be used
> for Breaks and Recommends.

indeed, good catch!
Thanks for raising this problem! Will get fixed by the next upload.

-- 
Regards
Carsten Schoenert

Bug#909266: [git-buildpackage/master] buildpackage, export-orig: support version substitution for --git-tarball-dir

[Luca Boccassi]

tag 909266 pending
thanks

Date:   Thu Sep 6 18:34:13 2018 +0200
Author: Luca Boccassi 
Commit ID: e5aedb16548a6a83223862b96ba2112e0c02c126
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=e5aedb16548a6a83223862b96ba2112e0c02c126
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=e5aedb16548a6a83223862b96ba2112e0c02c126

buildpackage, export-orig: support version substitution for 
--git-tarball-dir

Add support for passing %(version), %(hversion) and %(version%A%B) in
buildpackage --git-tarball-dir and export-orig --tarball-dir.

Closes: #909266

Signed-off-by: Luca Boccassi 

  

Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: Bug#911180: freeradius: freeradius refuses to start - missing libs

[Michael Stapelberg]

Dimitri, friendly ping? Would you prefer if I took care of this? If I don’t
hear back from you over the next week, I’ll go ahead :).

(An affected user just asked me in person about the status of this issue.)

On Tue, Nov 6, 2018 at 4:51 PM Michael Stapelberg 
wrote:

> Thanks for the reminder. It’s hard to keep track of everything that’s
> going on.
>
> The lintian tag description states:
>
> > The only time a binary or shared library in a Debian package should set
> RPATH or RUNPATH is if it is linked to private shared libraries in the same
> package. In that case, place those private shared libraries in
> /usr/lib/package. Libraries used by binaries in other packages should be
> placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
> case RPATH/RUNPATH is unnecessary.
>
> It seems like this is exactly what’s happening here?
>
> Can we try removing the rpath from where it can be removed, and overriding
> the lintian tag for the legitimate cases?
>
> I’d prefer to not open libraries to the public unless coordinated with
> upstream, as they need to be aware of the stability guarantees (e.g. when
> to bump the SONAME).
>
> Thanks!
>
> On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov 
> wrote:
>
>> Hey,
>>
>> On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg 
>> wrote:
>> >
>> > I still don’t quite understand why you stripped the rpaths to begin
>> with. Can you explain? I think that’d be good to understand before making a
>> decision :)
>> >
>>
>> Please recall that when you last tried to upload freeradius it got
>> autorejected by ftp masters due to rpath email from 2nd of June
>> from you to me
>>
>> """
>> freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath
>> usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu',
>> automatically rejected package.
>> freeradius-postgresql: If you have a good reason, you may override
>> this lintian tag.
>> freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath
>> usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected
>> package.
>> freeradius-iodbc: If you have a good reason, you may override this
>> lintian tag.
>> freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath
>> usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config',
>> automatically rejected package.
>> freeradius-python2: If you have a good reason, you may override this
>> lintian tag.
>> """
>>
>> And spot checking this revealed that rpath is redundant for most of
>> the modules shipped - hence i stripped rpath from them all.
>> However, clearly that was false for all of them as some of them do use
>> private lib as now analyzed.
>>
>> My preference is to not have rpath set on any of these, and simply
>> expose libfreeradius-dhcp.so and libfreeradius-eap.so as public
>> libraries.
>>
>> Also i'm pondering how come freeradius does not set ldpath when trying
>> to dlopen the plugins from the plugin dir cause that would also
>> work without rpath set on every plugin.
>>
>> Regards,
>>
>> Dimitri.
>>
>>
>>
>> > On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov 
>> wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg 
>> wrote:
>> >> >
>> >> > Sorry, didn’t see the merge request. I fixed my notification
>> settings, merged the MR, and gave you permission to the repository.
>> >> >
>> >>
>> >> No worries. I myself only starting to figure out how to correctly use
>> >> salsa. It is quite new in how everything works.
>> >>
>> >> So about the bug, here is the full scope of affected files:
>> >>
>> >> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e
>> File:
>> >> File: libfreeradius-dhcp.so
>> >> File: libfreeradius-eap.so
>> >> File: libfreeradius-radius.so
>> >> File: libfreeradius-server.so
>> >> File: proto_dhcp.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-dhcp.so]
>> >> File: proto_vmps.so
>> >> File: rlm_always.so
>> >> File: rlm_attr_filter.so
>> >> File: rlm_cache.so
>> >> File: rlm_cache_memcached.so
>> >> File: rlm_cache_rbtree.so
>> >> File: rlm_chap.so
>> >> File: rlm_counter.so
>> >> File: rlm_cram.so
>> >> File: rlm_date.so
>> >> File: rlm_detail.so
>> >> File: rlm_dhcp.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-dhcp.so]
>> >> File: rlm_digest.so
>> >> File: rlm_dynamic_clients.so
>> >> File: rlm_eap.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-eap.so]
>> >> File: rlm_eap_fast.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-eap.so]
>> >> File: rlm_eap_gtc.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-eap.so]
>> >> File: rlm_eap_leap.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-eap.so]
>> >> File: rlm_eap_md5.so
>> >>  0x0001 (NEEDED) Shared library:
>> [libfreeradius-eap.so]
>> >> File: 

Bug#914540: [20181124] mirrors.ocf.berkeley.edu: out of date, ftpsync-version

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problems

Hi!

It seems http://mirrors.ocf.berkeley.edu/debian/
is out of date
https://mirror-master.debian.org/status/mirror-info/mirrors.ocf.berkeley.edu.html

Please investigate.

o If you sync off kernel.org, you might want to pick a different site
  (do not use ftp.*.debian.org names, only http is guaranteed at
   those names and they do switch around.)
  https://mirror-master.debian.org/status/mirror-hierarchy.html might help
  you pick.

o Also, maybe update your ftpsync version.
  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914539: [20181124] mirrors.tecnoera.com: out of date

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problems

Hi!

It seems http://mirrors.tecnoera.com/debian/
is out of date
https://mirror-master.debian.org/status/mirror-info/mirrors.tecnoera.com.html

Please investigate.

o If you sync off kernel.org, you might want to pick a different site
  (do not use ftp.*.debian.org names, only http is guaranteed at
   those names and they do switch around.)
  https://mirror-master.debian.org/status/mirror-hierarchy.html might help
  you pick.


(Also, you might want to move from an arch-exclude to an arch-include
 config.)
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#914538: lintian: false positives with make prefixes on dh

[Stephen Kitt]

Package: lintian
Version: 2.5.113
Severity: normal
Tags: patch

Dear Maintainer,

When debian/rules includes a make prefix in front of dh, the use of dh
isn’t recognised and lintian reports
package-does-not-use-debhelper-or-cdbs.

The attached patch fixes this.

Regards,

Stephen


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

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

Versions of packages lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.18.25
ii  dpkg-dev  1.18.25
ii  file  1:5.30-1+deb9u2
ii  gettext   0.19.8.1-2
ii  gnupg [gpg]   2.1.18-8~deb9u3
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1+deb9u1
ii  libcgi-pm-perl4.35-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdigest-sha-perl5.96-1+b1
ii  libdpkg-perl  1.18.25
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1+deb9u1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libxml-simple-perl2.22-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-3+deb9u4
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

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

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

-- no debconf information
>From a36de5d0924aa9df78dba247d2b778951aa44a0f Mon Sep 17 00:00:00 2001
From: Stephen Kitt 
Date: Sat, 24 Nov 2018 16:25:48 +0100
Subject: [PATCH] Avoid false positives with make prefixes on dh

debian/rules which use a - or + prefix on dh trigger
package-does-not-use-debhelper-or-cdbs. This patch allows - or + in
front of dh and includes appropriate unit tests.

Signed-off-by: Stephen Kitt 
---
 checks/debhelper.pm|  4 ++--
 .../debian/debian/control.in   | 14 ++
 .../debian/debian/rules|  7 +++
 .../desc   |  6 ++
 .../tags   |  2 ++
 .../debian/debian/control.in   | 14 ++
 .../debian/debian/rules|  7 +++
 .../debhelper-package-uses-debhelper-with-prefix-plus/desc |  6 ++
 .../debhelper-package-uses-debhelper-with-prefix-plus/tags |  2 ++
 9 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/debian/debian/control.in
 create mode 100755 
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/debian/debian/rules
 create mode 100644 
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/desc
 create mode 100644 
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/tags
 create mode 100644 
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/debian/debian/control.in
 create mode 100755 
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/debian/debian/rules
 create mode 100644 
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/desc
 create mode 100644 
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/tags

diff --git a/checks/debhelper.pm b/checks/debhelper.pm
index 3b3c67e7b..810226f00 100644
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -87,7 +87,7 @@ sub run {
 }
 
 next if /^\s*\#/;
-if (m/^\s+-?(dh_\S+)/) {
+if (m/^\s+[@+-]?(dh_\S+)/) {
 my $dhcommand = $1;
 $build_systems{'debhelper'} = 1
   if not exists($build_systems{'dh'});
@@ -131,7 +131,7 @@ sub run {
 }
 

Bug#858045: Bug #858045: xcircuit: The File List Window can crash XCircuit

[Bernhard Übelacker]

Dear Maintainer, hello Gonçalo,
I tried to have a look at this issue, and could
reproduce it in a jessie and buster amd64 qemu VM.

As far as I see xcircuit tries to draw all files into one big pixmap.

(gdb) list filelist.c:480
477   pixheight = flfiles * FILECHARHEIGHT + 25;
478   if (pixheight < textheight) pixheight = textheight;
479
480   flistpix = XCreatePixmap(dpy, areawin->window, textwidth, 
pixheight,
481DefaultDepthOfScreen(xcScreen(w)));
(gdb) print pixheight 
$1 = 42039
(gdb) print textheight
$2 = 98
(gdb) print flfiles
$3 = 3001

Unfortunately, depending on the font size, we get then a height
of e.g. 42039, that is not allowed in the xserver:

(gdb) list ProcCreatePixmap
1392int
1393ProcCreatePixmap(ClientPtr client)
...
1415if (stuff->width > 32767 || stuff->height > 32767) {
1416/* It is allowed to try and allocate a pixmap which is 
larger than
1417 * 32767 in either dimension. However, all of the 
framebuffer code
1418 * is buggy and does not reliably draw to such big pixmaps, 
basically
1419 * because the Region data structure operates with signed 
shorts
1420 * for the rectangles in it.
1421 *
1422 * Furthermore, several places in the X server computes the
1423 * size in bytes of the pixmap and tries to store it in an
1424 * integer. This integer can overflow and cause the 
allocated size
1425 * to be much smaller.
1426 *
1427 * So, such big pixmaps are rejected here with a BadAlloc
1428 */
1429return BadAlloc;
1430}


So a check like in filelist.c:478 could be added
to limit pixheight to 32767, or give a error message like
in the "(Invalid Directory)" case.

Kind regards,
Bernhard


Client:
(gdb) bt
#0  XCreatePixmap (dpy=0x561a0f1f4f60, d=8389047, width=339, height=42039, 
depth=24) at ../../src/CrPixmap.c:50
#1  0x7f67bfa7d020 in listfiles (w=0x561a0f846e00, 
okaystruct=0x561a0fa27f60, calldata=0x0) at filelist.c:480
#2  0x7f67bfa7d51a in newfilelist (w=0x561a0f846e00, 
okaystruct=0x561a0fa27f60) at filelist.c:547
#3  0x7f67bfafaec2 in xctk_fileselect (clientData=0x561a0fa27f60, 
eventPtr=0x70ef86f0) at tclxcircuit.c:9567
#4  0x7f67c19c7ff5 in Tk_HandleEvent 
(eventPtr=eventPtr@entry=0x70ef86f0) at ./unix/../generic/tkEvent.c:1352
#5  0x7f67c19bb3b0 in HandleEventGenerate 
(interp=interp@entry=0x561a0f46b6f0, mainWin=mainWin@entry=0x561a0f624180, 
objc=objc@entry=4, objv=objv@entry=0x561a0f486840) at 
./unix/../generic/tkBind.c:3458
#6  0x7f67c19baaf1 in Tk_EventObjCmd (clientData=0x561a0f624180, 
interp=0x561a0f46b6f0, objc=6, objv=0x561a0f486830) at 
./unix/../generic/tkBind.c:2413
#7  0x7f67c1608a96 in TclNRRunCallbacks 
(interp=interp@entry=0x561a0f46b6f0, result=0, rootPtr=0x0) at 
./generic/tclBasic.c:4435
#8  0x7f67c1607ecf in Tcl_EvalObjv (interp=interp@entry=0x561a0f46b6f0, 
objc=objc@entry=6, objv=objv@entry=0x561a0f486830, flags=flags@entry=2097168) 
at ./generic/tclBasic.c:4165
#9  0x7f67c160964a in TclEvalEx (interp=0x561a0f46b6f0, 
script=0x70ef8af0 "event generate .filelist.listwin.win  
-button 2 ;  event generate .filelist.listwin.win  -button 2", 
numBytes=, flags=, line=line@entry=1, 
clNextOuter=clNextOuter@entry=0x0, outerScript=0x70ef8af0 "event generate 
.filelist.listwin.win  -button 2 ;  event generate 
.filelist.listwin.win  -button 2") at ./generic/tclBasic.c:5304
#10 0x7f67c16090f3 in Tcl_EvalEx (interp=, 
script=, numBytes=, flags=) at 
./generic/tclBasic.c:4969
#11 0x7f67c19b9705 in Tk_BindEvent (bindPtr=, 
eventPtr=eventPtr@entry=0x561a0f9f3aa0, tkwin=tkwin@entry=0x561a0f84c020, 
numObjects=, numObjects@entry=4, objectPtr=, 
objectPtr@entry=0x70ef8d20) at ./unix/../generic/tkBind.c:1505
#12 0x7f67c19bff4d in TkBindEventProc 
(winPtr=winPtr@entry=0x561a0f84c020, eventPtr=eventPtr@entry=0x561a0f9f3aa0) at 
./unix/../generic/tkCmds.c:319
#13 0x7f67c19c8173 in Tk_HandleEvent 
(eventPtr=eventPtr@entry=0x561a0f9f3aa0) at ./unix/../generic/tkEvent.c:1374
#14 0x7f67c19c8920 in WindowEventProc 
(evPtr=evPtr@entry=0x561a0f9f3a90, flags=flags@entry=-3) at 
./unix/../generic/tkEvent.c:1764
#15 0x7f67c16d0e17 in Tcl_ServiceEvent (flags=flags@entry=-3) at 
./generic/tclNotify.c:670
#16 0x7f67c16d1066 in Tcl_DoOneEvent (flags=-3) at 
./generic/tclNotify.c:903
#17 0x7f67c19c8d72 in Tk_MainLoop () at ./unix/../generic/tkEvent.c:2148
#18 0x7f67c19d741a in Tk_MainEx (argc=, argv=, appInitProc=0x561a0d485b30, interp=0x561a0f195f00) at 
./unix/../generic/tkMain.c:390
#19 0x561a0d485a0c in ?? ()
#20 0x7f67c07e7b17 in __libc_start_main 

Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

[Simon McVittie]

On Sat, 03 Nov 2018 at 14:07:18 -0700, Sean Whitton wrote:
> On Thu 04 Aug 2016 at 01:43PM +0100, Simon McVittie wrote:
> >> Other options
>
> I note that no such binary package exists right now.  Does this issue
> remain unresolved?  I also note recent discussion on d-devel.  Kindly
> update this bug with the present state of play.

The routes that I described as "other options" were not taken.

The current situation is that we have the two virtual packages that I
proposed in the original bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401#5
modulo the rename of dbus-default-session-bus to default-dbus-session-bus
as mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401#10 (trying to
continue/establish a convention that the preferred implementation of a
virtual package foo is default-foo). So:

* dbus-session-bus: anything providing the D-Bus well-known session bus
  for most or all user login sessions. If dbus-session-bus is
  installed, then programs in at least graphical login sessions can
  rely on seeing the $DBUS_SESSION_BUS_ADDRESS environment variable,
  the $XDG_RUNTIME_DIR/bus Unix socket, or some other way to discover a
  session bus that is supported by all the major D-Bus client libraries.

* default-dbus-session-bus: Debian's preferred implementation of
  dbus-session-bus, possibly architecture-specific.

Programs and desktop environments that require a D-Bus session bus and
cannot work without one should normally declare:

Depends: default-dbus-session-bus | dbus-session-bus

unless they have more specific requirements. Programs with weaker
dependencies can use a Recommends or a Suggests.

(Implementation detail: default-dbus-session-bus is currently provided
by dbus-user-session on Linux, and by dbus-x11 on non-Linux ports. On
Linux, dbus-x11 is a non-default implementation of dbus-session-bus,
to be used by people who prefer to have one session bus per X11 display,
or who don't want systemd or systemd-logind.)

smcv

Bug#914537: openmw: segfault at start

[Fred]

Package: openmw
Version: 0.44.0-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The latest build of this package (0.44.0-1+b1) makes the game crash at start on
my system (please see provided crash.log)




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

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

Versions of packages openmw depends on:
ii  libavcodec587:4.0.3-1
ii  libavformat58   7:4.0.3-1
ii  libavutil56 7:4.0.3-1
ii  libboost-filesystem1.67.0   1.67.0-10
ii  libboost-program-options1.67.0  1.67.0-10
ii  libboost-system1.67.0   1.67.0-10
ii  libbullet2.87   2.87+dfsg-3
ii  libc6   2.27-8
ii  libgcc1 1:8.2.0-9
ii  libgl1  1.1.0-1
ii  libmyguiengine3debian1v53.2.2+dfsg-2+b1
ii  libopenal1  1:1.19.1-1
ii  libopenscenegraph-3.4-131   3.4.1+dfsg1-4
ii  libopenthreads203.2.3+dfsg1-2+b9
ii  libqt5core5a5.11.2+dfsg-4
ii  libqt5gui5  5.11.2+dfsg-4
ii  libqt5widgets5  5.11.2+dfsg-4
ii  libsdl2-2.0-0   2.0.8+dfsg1-6
ii  libstdc++6  8.2.0-9
ii  libswresample3  7:4.0.3-1
ii  libswscale5 7:4.0.3-1
ii  libtinyxml2.6.2v5   2.6.2-4
ii  openmw-data 0.44.0-1

Versions of packages openmw recommends:
ii  openmw-launcher  0.44.0-1+b1

openmw suggests no packages.

-- no debconf information
*** Fatal Error ***
Segmentation fault (signal 11)
Address: (nil)

System: Linux debiananas 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) 
x86_64

Executing: gdb --quiet --batch --command=/tmp/gdb-respfile-i5hVPW
[New LWP 2002]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f31a65e424a in __waitpid (pid=2004, stat_loc=0x560a480fc78c, options=0) 
at ../sysdeps/unix/sysv/linux/waitpid.c:30

* Loaded Libraries
>FromTo  Syms Read   Shared Object Library
0x7f31a8bad3b0  0x7f31a8d2cfac  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosg.so.131
0x7f31a8ac6460  0x7f31a8ac77f8  Yes (*) 
/usr/lib/x86_64-linux-gnu/libOpenThreads.so.20
0x7f31a8a850f0  0x7f31a8ab148f  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosgParticle.so.131
0x7f31a890ae70  0x7f31a8a0d468  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosgUtil.so.131
0x7f31a878bb60  0x7f31a882768b  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosgDB.so.131
0x7f31a8673cd0  0x7f31a86e9f22  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosgViewer.so.131
0x7f31a85b81b0  0x7f31a85eb6d2  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosgGA.so.131
0x7f31a8562130  0x7f31a8563259  Yes (*) 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0
0x7f31a854a8f0  0x7f31a855860b  Yes (*) 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0
0x7f31a84e5360  0x7f31a852b045  Yes (*) 
/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.67.0
0x7f31a83de870  0x7f31a842b161  Yes (*) 
/usr/lib/x86_64-linux-gnu/libopenal.so.1
0x7f31a6f486b0  0x7f31a788e2d2  Yes (*) 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58
0x7f31a6cbb220  0x7f31a6e3d9ee  Yes (*) 
/usr/lib/x86_64-linux-gnu/libavformat.so.58
0x7f31a6c126e0  0x7f31a6c514e0  Yes (*) 
/usr/lib/x86_64-linux-gnu/libavutil.so.56
0x7f31a6b73220  0x7f31a6be8ddc  Yes (*) 
/usr/lib/x86_64-linux-gnu/libswscale.so.5
0x7f31a6b532b0  0x7f31a6b679cc  Yes (*) 
/usr/lib/x86_64-linux-gnu/libswresample.so.3
0x7f31a69ac2c0  0x7f31a6af1e41  Yes (*) 
/usr/lib/libMyGUIEngine.so.3debian1
0x7f31a6829ae0  0x7f31a68ecf3d  Yes (*) 
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
0x7f31a65fae40  0x7f31a6602dc4  Yes (*) 
/usr/lib/x86_64-linux-gnu/libtinyxml.so.2.6.2
0x7f31a65d8530  0x7f31a65e6101  Yes 
/lib/x86_64-linux-gnu/libpthread.so.0
0x7f31a6589b30  0x7f31a65c0e58  Yes (*) 
/usr/lib/x86_64-linux-gnu/libosgText.so.131
0x7f31a6492a20  0x7f31a654a17f  Yes (*) 
/usr/lib/x86_64-linux-gnu/libBulletCollision.so.2.87
0x7f31a64326d0  0x7f31a64463ba  Yes (*) 
/usr/lib/x86_64-linux-gnu/libLinearMath.so.2.87
0x7f31a63dc220  0x7f31a63df5df  Yes (*) 
/usr/lib/x86_64-linux-gnu/libGL.so.1
0x7f31a5e92ab0  0x7f31a6210705  Yes (*) 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
0x7f31a588be50  0x7f31a5c51cee  Yes (*) 

Bug#914536: lua-cyrussasl: Package built only for lua 5.1

[Marco Gaiarin]

Package: lua-cyrussasl
Version: 1.0.0-6
Severity: important

Dear Maintainer,

your package seems built only for lua 5.1, so does not work with lua 5.2.

Please, rebuild it also for lua 5.2 (and lua 5.3, indeed), or at least
rename it 'lua5.1-cyrussasl'.

Thanks.

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

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

Versions of packages lua-cyrussasl depends on:
ii  libc6  2.19-18+deb8u10
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  multiarch-support  2.19-18+deb8u10

lua-cyrussasl recommends no packages.

lua-cyrussasl suggests no packages.

-- no debconf information

Bug#914534: neutron-fwaas: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: neutron-fwaas 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of neutron-fwaas
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#914535: nova: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: nova 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of nova debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#914531: shim-signed: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: shim-signed 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of shim-signed
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#914532: neutron: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: neutron 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of neutron debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#914533: neutron-vpnaas: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: neutron-vpnaas 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of neutron-vpnaas
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#914530: prosody: broken LDAP support

[W. Martin Borgert]

Package: prosody
Version: 0.11.0-1
Severity: grave

(I'm abusing the "grave" severity here to prevent prosody going
to testing, "important" would be correct. If there were a
prosody-ldap package, that one would deserve the "grave"
severity bug.)

As long as lua-ldap does not support lua5.2 (#814218), LDAP
support cannot work. This will break prosody installations, that
depend on that feature, such as Debians.

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Jonathan de Boyne Pollard]

Dmitry Bogatov:

I believe I already wrote in init-d-script(5) correct invocation: 
#!/usr/bin/env /lib/init/init-d-script


That's not what was in the skeleton that you just got rid of; which had 
more attention paid to it than the example in the manual page had, I 
suspect.


The next portability bump on this road, discussed many times over the 
years, is to hit platforms where env is not in /usr/bin.  This is not 
the case with Debian operating systems, though, fortunately.  And I 
doubt that you'll have many dealings with FreeBSD kernels from before 
2005, where the #! mechanism was more like MacOS.  (-:


* https://unix.stackexchange.com/questions/29608/

* https://unix.stackexchange.com/questions/111802/

* https://unix.stackexchange.com/questions/361794/

Bug#914373: octave-statistics: accessing installed functions is needlessly obscure

[Rafael Laboissière]

Control: severity -1 wishlist
Control: reassign -1 octave 4.0.3-3
Control: retitle -1 octave: Document the need for pkg load

* Sébastien Villemot  [2018-11-24 11:56]:


Le samedi 24 novembre 2018 à 11:43 +0100, Rafael Laboissière a écrit :


[snip]

Do the other members of the DOG agree with this change?


That seems excessive to me. The fact that OF packages are not auto- 
loaded is the consequence of a global setting (in Octave itself), so it 
does not make sense to document it in individual packages.


I share your opinion.  Adding a README.Debian for each package is 
excessive and would be a maintenance burden, as well.  Besides that, this 
is not really a bug. I am hereby decreasing the severity of this bug 
report from normal to wishlist.


I would rather update the README.Debian of octave. It currently tells 
never to use the "pkg" command, which is bad advice, since that command 
is needed to load the packages.


Yes, documenting it in the README.Debian of octave is the sensible thing 
to do.  I am hereby reassigning this bug report to the octave package and 
adjusting its title.


I think that the current advice in the README.Debian of octave regards 
the use of "pkg install".  At any rate, the wording is wrong and must be 
fixed.


Rafael

Bug#614775: bash-completion: perl -d inhibits filename completion

[Gabriel F. T. Gomes]

Thanks for the patch.

I adpated it for current sources and forwarded it upstream as
https://github.com/scop/bash-completion/pull/258.

I'll apply it to Debian's bash-completion for the next upload.

Bug#914529: lua-dbi: please provide a lua5.2 version in stretch-backports

[W. Martin Borgert]

Source: lua-dbi
Version: 0.7.1-1
Severity: wishlist

To provide a stable backport of prosody 0.11.0, some lua
packages need lua5.2 support via backports, too. Just
backporting the testing version of lua-dbi is probably the way
to go. I'll do the backport myself, if nobody objects.

Bug#913756: tootle: Tootle window opens and closes immediately

[Federico Ceratto]

Temporary workaround: download the package for your architecture from
https://snapshot.debian.org/package/granite/5.1.0-2/\#libgranite5_5.1.0-2
and install it with sudo dpkg -i 

-- 
Federico

Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2

[Mattia Rizzolo]

[ note how I removed 914347 from the recipients and kept only 914483 ]

On Fri, Nov 23, 2018 at 09:43:10PM +0100, Gert Wollny wrote:
> Am Freitag, den 23.11.2018, 20:14 +0100 schrieb Mattia Rizzolo:
> > Hi,
> > 
> > so, if you don't particularly mind, I'm happy to just take the least
> > and fix all the involved packages here, so src:vtk7 
> I just uploaded vtk7, I knew where to look because I did the changes
> that made the libraries go away, and the python thing was not so
> difficult after all.

Thanks, that one looks good to me.

> > Gert: you mention you gave up on symbols, but at least in gdcm's
> > changelog I don't see anything about that.  Had you had troubles
> > there as well?
> TBH I never tried with gdcm, I think I started to upload the package
> when it was already at version 2.4 and I didn't even note that there is
> a script for the symbols there (which points at 2.2).

regardless of that script (I don't particularly like
pkgkde-symbolshelper tbh, also I don't think that script is doing that
much to help…), I notice that the libgdcm2.8 library is indeed not
nice...

I tried to compared the symbols exported between several versions, and
they all differ.  And not just from some templates or stuff leaked from
the std library; for example between 2.8.7-1 and 2.8.7-2 stuff like this
disappered from libgdcmDSED.so.2.8:
_ZN10gdcmstrict7DataSet6RemoveERKN4gdcm3TagE@Base
and many others...  I haven't looked deep so I couldn't quite understand
where that is coming from, but given that this happens quite frequently
but clearly nothing breaks badly all the time I guess it's just
something that shouldn't have been exported in the first place?

> When I started packaging some of my software (mia) that has lots of
> templates I just noted that getting symbols right there is kind of an
> infinite task because each arch would need its own file because of
> templates that on 64 bit use some types that are not available, and
> were not instanciated on 32 bit systems. Maybe the tools are better
> now, but at that time (2012) it was all kind of wired.

If it's only 32/64 bits difference, that's easy to do since there is an
arch-bits filter you can use.  But I acknowledge that for many c++
libraries where their developers don't explicitly try to keep their
exported ABI tidy is very easy to get a mess.

This line is from a diff between libgdcm2.8 2.8.7-2 vs 2.8.7-5:
- gdcm::Attribute<(unsigned short)32, (unsigned short)17, 512, 
1>::GetAsDataElement() const@Base 2.8.7
+ gdcm::Attribute<(unsigned short)32, (unsigned short)19, 512, 
1>::GetAsDataElement() const@Base 2.8.7

That's clearly something that shouldn't have leaked here...

But that kind of things make impossible even thoughts like "I'll keep a
.symbols only for amd64" (which is a valid idea to have).


At the same time, libvtkgdcm is much more tidy, so at least I will start
adding a .symbols file to that one...

> > What I would welcome your help with is explaining the camitk FTBFS on
> > i386.
> Just had as peek, my guess is that this will help: 
> 
> ifeq ($(DEB_BUILD_ARCH),i386)

Note that here you probably meant DEB_HOST_ARCH, not build arch.

>   export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
> endif
> 
> The same was needed for ITK because they write tests with floating
> point values apparently comparing with high accuracy, and on i386
> optimizations can lead to the used of intermediate 80 bit floating
> point values that then result in test failures because the references
> were tuned for 64 bit floating point values. Adding above flag makes
> sure that intermediate results are not keps in these 80 bit FPU
> registers.

ACK, thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914528: game-data-packager: kyrandia1: Add support for new GOG installer

[cacatoes]

Package: game-data-packager
Version: 61

Hello,

Here is a simple patch for Kyrandia 1 adding support for a GOG
installer.

Mew,
>From 514f3e7ee4f1ee0fa8e823766e6a605368e34664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?cacato=C3=A8s?= 
Date: Sat, 24 Nov 2018 15:20:50 +0100
Subject: [PATCH] kyrandia1: Add support for new GOG installer

---
 data/kyrandia1.yaml | 9 +
 1 file changed, 9 insertions(+)

diff --git a/data/kyrandia1.yaml b/data/kyrandia1.yaml
index 730560b5..41095dee 100644
--- a/data/kyrandia1.yaml
+++ b/data/kyrandia1.yaml
@@ -56,6 +56,14 @@ files:
 - assets english
 - manual.pdf
 
+  setup_legend_of_kyrandia_2.0.0.11.exe:
+unpack:
+  format: innoextract
+provides:
+- assets common
+- assets english
+- manual.pdf
+
   setup_legend_of_kyrandia_1.1_(20270).exe:
 unpack:
   format: innoextract
@@ -99,6 +107,7 @@ files:
 groups:
  archives: |
   53747640  562a149d31069f70c3ab92f05aca96e0 setup_legend_of_kyrandia_2.1.0.14.exe
+  55844432  0001370b8bb598b9a9289a2c3d29 setup_legend_of_kyrandia_2.0.0.11.exe
   54434128  03b283612879edeb4eecfd111662d0ee setup_legend_of_kyrandia_1.1_(20270).exe
   53761456  087261e9ec6de9b395fee90b028f6e8b setup_legend_of_kyrandia_german_2.1.0.14.exe
   54438336  49d9bd9f8cc0476e6477dc69253fd2f4 setup_legend_of_kyrandia_1.1_(german)_(20270).exe
-- 
2.19.1

Bug#914527: dwarves: update package description

[Holger Levsen]

package: dwarves
severity: minor
x-debbugs-cc: Domenico Andreoli , 
debian-de...@lists.debian.org

On Sat, Nov 24, 2018 at 03:28:37PM +0100, Domenico Andreoli wrote:
>   after some ~7 years of inactivty I've been able to put a new upstream
> release of dwarves together. It's at https://salsa.d.o/debian/dwarves.

this made me read the package description which reads/starts:

Description-en: set of advanced DWARF utilities
 This package contains tools that use the DWARF debugging information
 inserted in ELF binaries by the compiler. This information is already
 used by debuggers (e.g. GDB), and more recent tools such as systemtap.

I'd suggest you update this to

Description-en: set of advanced DWARF utilities
 This package contains tools that use the DWARF debugging information
 inserted in ELF binaries by the compiler. This information is used by
 debuggers (e.g. GDB), and other tools such as systemtap.

or some such.

> In the meanwhile that I resurrect my old 1024 bits key, sign the new one
> and also get some signatures I might have somewhere, I need a sponsor
> to upload this package. Any volunteer?

sorry, not me.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#914526: linux-image-4.18.0-0.bpo.1-amd64: Invalidating filesystems can corrupt dentry table leading to busy loop in kernel.

[Colm Buckley]

Package: src:linux
Version: 4.18.6-1~bpo9+1
Severity: important
Tags: upstream patch

Please see 
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus
 - invalidating
filesystems can cause dentry table corruption leading to busy loop in kernel. 
Easily triggered from userspace (observed
triggers using NFS, XFS and ZFS).

Patch supplied upstream; please consider cherrypicking this to BPO kernel.

Thanks.


-- Package-specific info:
** Version:
Linux version 4.18.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.18.6-1~bpo9+1 
(2018-09-13)

** Command line:
BOOT_IMAGE=/boot@/boot/vmlinuz-4.18.0-0.bpo.1-amd64 root=ZFS=rpool/boot ro

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: 
product_name: 
product_version: 
chassis_vendor: 
chassis_version: 
bios_vendor: Intel Corporation
bios_version: MYBDWi30.86A.0038.2016.0913.1446
board_vendor: Intel Corporation
board_name: NUC5i3MYBE
board_version: H47781-206

** Loaded modules:
xt_nat
cfg80211
xt_tcpmss
ipt_MASQUERADE
xt_limit
xt_recent
ip6table_nat
nf_nat_ipv6
ip6t_REJECT
nf_reject_ipv6
ip6table_mangle
ip6table_raw
nf_conntrack_ipv6
nf_defrag_ipv6
nf_log_ipv6
ip6table_filter
ip6_tables
xt_comment
iptable_nat
nf_nat_ipv4
ipt_REJECT
nf_reject_ipv4
xt_addrtype
bridge
xt_mark
iptable_mangle
xt_TCPMSS
xt_tcpudp
xt_CT
iptable_raw
xt_multiport
nf_conntrack_ipv4
nf_defrag_ipv4
xt_conntrack
xt_NFLOG
xt_LOG
nf_log_ipv4
nf_log_common
nf_nat_tftp
nf_nat_snmp_basic
nf_conntrack_snmp
nf_nat_sip
nf_nat_pptp
nf_nat_proto_gre
nf_nat_irc
nf_nat_h323
nf_nat_ftp
nf_nat_amanda
ts_kmp
nf_conntrack_amanda
nf_nat
nf_conntrack_sane
nf_conntrack_tftp
nf_conntrack_sip
nf_conntrack_pptp
nf_conntrack_proto_gre
nf_conntrack_netlink
nf_conntrack_netbios_ns
nf_conntrack_broadcast
nf_conntrack_irc
nf_conntrack_h323
nf_conntrack_ftp
nf_conntrack
libcrc32c
crc32c_generic
iptable_filter
nfnetlink_queue
nfnetlink_log
nfnetlink
bluetooth
drbg
ansi_cprng
ecdh_generic
rfkill
crc16
pppoe
pppox
ppp_generic
slhc
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
iTCO_wdt
iTCO_vendor_support
evdev
kvm
i915
irqbypass
crct10dif_pclmul
crc32_pclmul
pl2303
drm_kms_helper
usbserial
ghash_clmulni_intel
sg
drm
intel_cstate
mei_me
mei
intel_uncore
lpc_ich
pcspkr
efi_pstore
intel_rapl_perf
efivars
video
button
acpi_pad
pcc_cpufreq
bonding
8021q
garp
mrp
stp
llc
efivarfs
ip_tables
x_tables
autofs4
zfs(PO)
zunicode(PO)
zavl(PO)
icp(PO)
zcommon(PO)
znvpair(PO)
spl(O)
sd_mod
crc32c_intel
ahci
libahci
libata
igb
i2c_algo_bit
scsi_mod
dca
aesni_intel
xhci_pci
ehci_pci
xhci_hcd
ehci_hcd
aes_x86_64
crypto_simd
i2c_i801
cryptd
glue_helper
usbcore
e1000e
usb_common
fan
thermal

** PCI devices:
not available

** USB devices:
Bus 001 Device 002: ID 8087:8001 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 2109:0813 VIA Labs, Inc. 
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial 
Port [pl2303]
Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 002 Device 002: ID 2109:2813 VIA Labs, Inc. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


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

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

Versions of packages linux-image-4.18.0-0.bpo.1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.18.0-0.bpo.1-amd64 recommends:
ii  apparmor 2.11.0-3+deb9u2
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.18.0-0.bpo.1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.02~beta3-5+deb9u1
pn  linux-doc-4.18  

Versions of packages linux-image-4.18.0-0.bpo.1-amd64 is related to:
ii  firmware-amd-graphics 20180825+dfsg-1~bpo9+1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20180825+dfsg-1~bpo9+1
ii  firmware-misc-nonfree 

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Jonathan de Boyne Pollard]

Michael Biebl:
fwiw, this is why I suggested to provide a C implementation of 
init-d-script which can be used as an interpreter


That's how it was addressed in 2007.

* 
https://github.com/OpenRC/openrc/commit/5af58b45146ab5253ca964738f4e45287bf963d4


* 
http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2018-November/000340.html


The OpenRC people have already learned many of the lessons through 
experience here, long since.  There are the difficulties in handling rc 
scripts that people have symbolically linked to a common worker script, 
for example.  They also went through the exit code of the interpreter 
thing in a minor way with exit 0 when starting a service in 2008 and 
again in more detail in 2011.


* https://bugs.gentoo.org/show_bug.cgi?id=351160

Bug#914525: mosquitto: fails to build on non-linux

[Andreas Henriksson]

Source: mosquitto
Version: 1.5.4-1
Severity: normal
Tags: patch

Dear Maintainer,

I noticed the new version of mosquitto failed to build on hurd.

My thoughts was that this was because of the long-standing breakage
in libsystemd-dummy that no non-linux porter seems to have had time
to fix (see #830935). I fixed up libsystemd-dummy to verify this
but unfortunately all the blame can not be put on non-linux porters
this time. (I'll upload the fixed version shortly.)

Apparently conf.mk hard-codes the linker flags instead of using
pkg-config to retrieve them (which would end up blank with
libsystemd.pc from libsystemd-dummy). Thus there are two options
to fix mosquitto build on hurd:
1. start using pkg-config and replace the hardcoded -lsystemd
2. include special-casing in debian/rules

The attached patch does the latter as it seemed easiest and least
controversial. Please note the patch has only been (build-)tested on
hurd, so you might want to give it a spin yourself (on linux) and verify
the correct configure arguments are used.

Regards,
Andreas Henriksson
diff -Nru mosquitto-1.5.4/debian/changelog mosquitto-1.5.4/debian/changelog
--- mosquitto-1.5.4/debian/changelog2018-11-08 13:34:59.0 +
+++ mosquitto-1.5.4/debian/changelog2018-11-24 13:41:32.0 +
@@ -1,3 +1,12 @@
+mosquitto (1.5.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Only enable WITH_SYSTEMD=yes on linux
+- this is needed as mosquitto build system doesn't use pkg-config
+  and instead hardcodes systemd linker flags.
+
+ -- Andreas Henriksson   Sat, 24 Nov 2018 13:41:32 +
+
 mosquitto (1.5.4-1) unstable; urgency=medium
 
   * New upstream release (Closes: #911104).
diff -Nru mosquitto-1.5.4/debian/rules mosquitto-1.5.4/debian/rules
--- mosquitto-1.5.4/debian/rules2018-11-08 13:34:59.0 +
+++ mosquitto-1.5.4/debian/rules2018-11-24 13:41:32.0 +
@@ -1,8 +1,10 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 export prefix=/usr
-export libdir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+export libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
 
 %:
dh $@
@@ -14,7 +16,10 @@
# Don't process CMake rules, CMakeLists.txt is only included for 
Windows/Mac support.
 
 override_dh_auto_build:
-   make WITH_BUNDLED_DEPS=no WITH_ADNS=yes WITH_WRAP=yes 
WITH_WEBSOCKETS=yes WITH_STRIP=no WITH_SYSTEMD=yes
+ifneq (,$(findstring linux,$(DEB_HOST_ARCH_OS)))
+   CONFARGS="WITH_SYSTEMD=yes"
+endif
+   make WITH_BUNDLED_DEPS=no WITH_ADNS=yes WITH_WRAP=yes 
WITH_WEBSOCKETS=yes WITH_STRIP=no $(CONFARGS)
 
 override_dh_auto_test:
 

Bug#914126: svtplay-dl: bugs out on urplay.se

[Cristian Ionescu-Idbohrn]

On Fri, 23 Nov 2018, Olof Johansson wrote:
> On 18-11-19 18:37 +0100, Cristian Ionescu-Idbohrn wrote:
> > This is what I see:
> ...
> > requests.exceptions.SSLError: 
> > HTTPSConnectionPool(host='streaming-loadbalancer.ur.se', port=443): Max 
> > retries exceeded with url: /loadbalancer.json (Caused by 
> > SSLError(SSLError("bad handshake: Error([('SSL routines', 
> > 'ssl_choose_client_version', 'unsupported protocol')],)",),))
> > 
> > when trying to download:
> > 
> > https://urplay.se/program/204949-roster-fran-australiens-aboriginer
> > 
> > for example.  Works fine when playing it in chromium, though.
> > 
> > Downloading from svtplay.se works fine, though.
> 
> Thanks for the report, I have been postponing upgrading to the
> new 2.0+ version, but should get on that asap. Hopefully that
> should solve it.

Doesn't seem so :(  I tested with master (2.1-14-g72143b7).  Similar 
problem.  Attaching a trace done with that version.


Cheers,

-- 
Cristian$ ~/DEVEL/svtplay-dl/svtplay-dl --verbose -P hls -g 
https://urplay.se/program/204949-roster-fran-australiens-aboriginer
DEBUG [1543056480.152882] 
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/utils/getmedia.py/get_media: version: 
2.1-14-g72143b7
DEBUG [1543056480.1539545] 
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/service/__init__.py/__init__: service: 
urplay
DEBUG [1543056480.1540117] 
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/utils/http.py/request: HTTP getting 
'https://urplay.se/program/204949-roster-fran-australiens-aboriginer'
DEBUG [1543056480.155448] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting 
new HTTPS connection (1): urplay.se:443
DEBUG [1543056480.2892246] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_make_request: 
https://urplay.se:443 "GET /program/204949-roster-fran-australiens-aboriginer 
HTTP/1.1" 200 16422
DEBUG [1543056480.292382] 
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/utils/http.py/request: HTTP getting 
'https://streaming-loadbalancer.ur.se/loadbalancer.json'
DEBUG [1543056480.2933757] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting 
new HTTPS connection (1): streaming-loadbalancer.ur.se:443
DEBUG [1543056480.3410475] 
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented 
Retry for (url='/loadbalancer.json'): Retry(total=4, connect=5, read=5, 
redirect=None, status=None)
WARNING [1543056480.341197] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying 
(Retry(total=4, connect=5, read=5, redirect=None, status=None)) after 
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 
'ssl_choose_client_version', 'unsupported protocol')],)",),)': 
/loadbalancer.json
DEBUG [1543056480.3413193] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting 
new HTTPS connection (2): streaming-loadbalancer.ur.se:443
DEBUG [1543056480.3939955] 
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented 
Retry for (url='/loadbalancer.json'): Retry(total=3, connect=5, read=5, 
redirect=None, status=None)
WARNING [1543056480.994881] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying 
(Retry(total=3, connect=5, read=5, redirect=None, status=None)) after 
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 
'ssl_choose_client_version', 'unsupported protocol')],)",),)': 
/loadbalancer.json
DEBUG [1543056480.9951062] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting 
new HTTPS connection (3): streaming-loadbalancer.ur.se:443
DEBUG [1543056481.0753078] 
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented 
Retry for (url='/loadbalancer.json'): Retry(total=2, connect=5, read=5, 
redirect=None, status=None)
WARNING [1543056482.2757819] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying 
(Retry(total=2, connect=5, read=5, redirect=None, status=None)) after 
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 
'ssl_choose_client_version', 'unsupported protocol')],)",),)': 
/loadbalancer.json
DEBUG [1543056482.2761137] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting 
new HTTPS connection (4): streaming-loadbalancer.ur.se:443
DEBUG [1543056482.3429654] 
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented 
Retry for (url='/loadbalancer.json'): Retry(total=1, connect=5, read=5, 
redirect=None, status=None)
WARNING [1543056484.7437494] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying 
(Retry(total=1, connect=5, read=5, redirect=None, status=None)) after 
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 
'ssl_choose_client_version', 'unsupported protocol')],)",),)': 
/loadbalancer.json
DEBUG [1543056484.7439423] 
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting 
new HTTPS connection (5):