Bug#921707: RFP: glowing-bear -- Web-based graphical interface for WeeChat

[Giovanni Mascellani]

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

   Package name: glowing-bear
Version: 0.7.1
Upstream Author: Lorenz Hübschle-Schneider and others
URL: https://github.com/glowing-bear/glowing-bear
License: GPL-3
Description: Web-based graphical frontend for WeeChat
Glowing Bear is a web-based graphical frontend for the WeeChat IRC
client. It relies on WeeChat to do all the heavy lifting and then
provides some nice features on top of that, like embedding images,
videos, and other content.

Glowing Bear communicates with WeeChat using the (possibly encrypted)
relay protocol offered by WeeChat.

Glowing Bear is written in JavaScript and runs as an Electron application.


Thanks to will have some time to package it properly. I am unfortunately
not very experienced with JavaScript applications.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#820069: dhcpcd5: configures interface without being asked to

[Scott Leggett]

On Wed, 16 Jan 2019 20:20:04 -0800 Adam McKenna  wrote:
> I was hit by this bug last night.  After plugging a new Internet provider
> into my local network, my Debian router automatically added an IP address
> and default route to the new device.  This resulted in my entire home's
> Internet access being disrupted as the router tried to route traffic via
> the new device.  What's worse is that when the default route is removed
> it's automatically added back.

Hi Adam,

Thanks for the report.

Do I understand correctly that you plugged some kind of USB modem into
your router which was running dhcpcd, so that the modem showed up as a
new network interface?

In that situation, as you found, dhcpcd will run in master mode by
default - see the manpage for what that means.

> dhcpcd is STILL bringing up this interface even after disabling the DHCP
> server on the AT device.  The IP address that dhcpcd added is not visible
> in ifconfig.  It only shows up when you run 'ip addr list'.

Yes, ifconfig is deprecated - please only use `ip ...`.

> This is very serious security bug.  This bug could easily be exploited by
> an attacker to force routing of traffic via the attacker's device.
>
> Relevant logs/config files:
> 
> Jan 17 03:56:32 raspberrypi dhcpcd[16922]: eth0: Router Advertisement from
> fe80:[removed]
> Jan 17 03:56:32 raspberrypi dhcpcd[16922]: eth0: adding address [removed
> ipv6 address]
> Jan 17 03:56:32 raspberrypi dhcpcd[16922]: eth0: soliciting a DHCPv6 lease
> Jan 17 03:56:35 raspberrypi dhcpcd[16922]: eth0: leased 192.168.1.67 for
> 86400 seconds
> Jan 17 03:56:35 raspberrypi dhcpcd[16922]: eth0: adding route to
> 192.168.1.0/24
> Jan 17 03:56:35 raspberrypi dhcpcd[16922]: eth0: adding default route via
> 192.168.1.254
> 
> /etc/network/interfaces.d/eth0
> ==
> auto eth0
> iface eth0 inet static
> address [removed]
> netmask 255.255.255.0
> 
> auto eth0:0
> allow-hotplug eth0:0
> iface eth0:0 inet static
> address 192.168.1.1
> netmask 255.255.255.0
> 
> 
> /etc/dhcpcd.conf
> ===
> ddns-update-style none;
> default-lease-time 600;
> max-lease-time 7200;
> authoritative;
> log-facility local7;
> 
> subnet [removed] netmask 255.255.255.0 {
>   range [removed] [removed];
>   option broadcast-address [removed];
>   option routers [removed];
>   default-lease-time 600;
>   max-lease-time 7200;
>   option domain-name "local-network";

You can avoid this issue by adding `allowinterfaces ...` or
`denyinterfaces ...` as appropriate to the /etc/dhcpcd.conf file.

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#920876: xfce4-notes: Not functioning

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-02-08 at 10:10 +1100, Dmitry Smirnov wrote:
> Thanks. Maximiliano diagnosed the problem in #907297:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907297#35
> 
> It is happening because of ".gtkrc-2.0" file as per
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907297#40
> 
> As workaround I've deleted "~/.gtkrc-2.0" and the problem was fixed.
> I do not know how that file was created...

I noticed that bug, but unless the syntax in that .gtkrc-2.0 is completely
wrong, I'm unsure why it was causing the bug for you while selecting the
Breeze theme (in the Appareance settings) doesn't.
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxdP8IACgkQ3rYcyPpX
RFuccwf+OW55V2Qearvtf82L+wkcrwRrC8tm/u7oNoBhdXuXZyKfC0HrCTp2MTFf
sZzvCWZRxsjdEbM1ggEkoph8iCBscrBNrZjUU+nyNBDQG1VdQa5xn2cBnGICe8P/
WJQ/s4ly6BQUBwJ3KHwrYBFQMcyzDtFebZjDzQx+PkldaAyw9M8DHRcQv+6QULdi
pfplBC7Xm1OMTvE1wbHO6GdLtzTXfqU0W1lNm0JR4JnrxzuKpnK810qW/rWR2X8w
SmXwTrs4CLD6NG3TB49z/68OwznibSYof4t2B1l/qRfAm2zZ0degtKEou4N11ubk
jNz2mvxh+YX5cvAp7NqQTCaOAaDBdA==
=o0+Z
-END PGP SIGNATURE-

Bug#846278: reference to vt-switch problem?

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2019-01-31 at 12:49 +0100, Yves-Alexis Perez wrote:
> On Thu, 2019-01-31 at 11:20 +0100, Tomas Pospisek wrote:
> > Do you have a reference for a bug report in the bts for this? Or asked 
> > slightly differently: are the X maintainers and/or upstream aware of this 
> > problem and are tracking it (again I would appreciate a reference).
> 
> Hi,
> 
> I don't know about any reference on this, in Debian BTS or upstream (maybe
> it
> exists, but I don't know about it).
> 
> I think having a minimal reproducer was always a bit problematic and thus it
> might have never been reported.

For what it's worth, it seems that it might not entirely be linked to
lightdm/light-locker. Other people apparently reproduce the same kind of
situation (no backlight, need for a vt-switch) in other environment. It
happens usually with Intel graphics cards and involves suspend/resume cycles
and maybe docking/undocking.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxdPyIACgkQ3rYcyPpX
RFvnwAf8ChxwDGWcKO5qk/X94tcSbVpJkARU14EfUORsWL+HpV5da3I8kHvg5XQV
eOAh2u9zEP+/UPr8n2cbtwIwVEzCZAAHJnwX+Nm/rf4lUs5WvJXjdb1XixJjM0gi
bCs8kpON/f7uPNNObSFeirbo9wSrC9UoQ6nwFXSz/8ydRvh2USBwOP6Es6/FEpq9
Gf/nNBlldMNLfi52gmfBG6T9m07BPH3AdKRYBxi3yyxvCxHDOpnBsxz3jXdF7/PR
5uzFF36zrlQR+6rcwXrhDiC2N033c14pGbWIX7Ta6Qw+MT7IYMn220I/7PrjaVhd
EqA2mCRJiJ8CStg+KbJPtpiAxvcCBQ==
=yPmX
-END PGP SIGNATURE-

Bug#921710: RM: ruby-fog-ecloud -- ROM; not required anymore, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency on ruby-fog and ruby-fog
itself is marked for removal. No othere reverse dependencies.

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Aurelien Jarno]

On 2019-02-08 14:33, Roman Mamedov wrote:
> On Fri, 8 Feb 2019 10:21:41 +0100
> Aurelien Jarno  wrote:
> 
> > What is the content of /etc/default/locale? it looks like you have an
> > additional entry than the LANG one set by dpkg-reconfigure locales.
> 
> "dpkg-reconfigure locales" only writes LANG=C.UTF-8 (or any other accordingly)
> to that file. This results in the "locale" output that I posted above
> (including after a relogin or reboot). There were no lines aside from that
> in /etc/default/locale.

Yes, that's normal that only LANG is set, as it's the one with less
priority. That said there was clearly something setting LC_ALL to
en.US-UTF-8 before, you might want to grep /etc for that. When only LANG
is set, you should get and output like this one:

LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

Note how LC_ALL is unset.

Aurelien

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

Bug#921711: libusrsctp1: typo in homepage

[Jonas Smedegaard]

Control: tags -1 pending

Quoting Michael Becker (2019-02-08 09:48:37)
> Package: libusrsctp1
> Version: 0.9.3.0+20190127-1
> Severity: minor
> 
> Homepage is https://github.com/sctplib/usrsctp
> but must be https://github.com/sctplab/usrsctp

Thanks!

Applied in git, and will be included in next packaging release.


 - Jonas

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

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


signature.asc
Description: signature

Bug#921709: RM: r-cran-v8 [armel hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- ROM; no longer builds

[Dylan Aïssi]

Package: ftp.debian.org
Severity: normal

Hi,

The old r-cran-v8 version (1.5) was built against libv8-3.14-dev which
is too buggy for Buster. Since the new version 2.0, upstream made it
compatible to libnode-dev. So, there was a change in the build-deps of
r-cran-v8 which lead to missing builds due to differential
architectures supported by libv8 and libnode. At least the missing
build for armel will block the transition to buster. According to

$ rmadison r-cran-v8 | grep "unstable "
r-cran-v8  | 1.5-3| unstable  | source, armel,
hurd-i386, kfreebsd-amd64, kfreebsd-i386
r-cran-v8  | 2.0+dfsg-1| buildd-unstable | source, amd64, arm64,
armhf, i386, mips, mipsel, ppc64el, s390x
r-cran-v8  | 2.0+dfsg-1| unstable  | source, amd64, arm64,
armhf, i386, mips, mipsel, ppc64el, s390x

version 1.5-3 should be removed from Debian.

Thanks a lot.

Best,
Dylan

Bug#921708: RM: ruby-fog-brightbox -- ROM; not required anymore, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency on ruby-fog and ruby-fog
itself is marked for removal. No othere reverse dependencies.

Bug#756770: [Pkg-xfce-devel] Bug#756770: Bug#756770: Bug#756770: xfce4-whiskermenu-plugin: it segfaults

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2014-08-06 at 21:21 +0200, Moritz Molle wrote:
> As to when the plugin crashes in the panel: I add it to the panel and 
> the icon (the menubutton) gets displayed. When I click it, the frame 
> opens in which the menu should be displayed, the loading indicator 
> rotates, 1-2-3 secs, and *poof* it's gone.

Hi,

it's been (quite) a while. Does the current version still crashes for you?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxdUfUACgkQ3rYcyPpX
RFsXzAf/cQiwFUoTNLelg/CQbWVHZM3BJxJ6TAptCrD7WEqJEGtd1qbCM1VhKxlo
XlbZi9vdH3DclzL3NQiNGWCzdcUsNZZsdwijkKAiv7C/EWFbng5EdhLxY4QjQj0J
mZo7g2gfBimfbtvQkAYQF5ZBKajLXsUsXHO0JUPe4O+X2jcVAIK1RhA4zsIQL9Ob
POcSBqR6nTFjGIkQRTJTWDa8MMCXRzqe4DDskjvRw+Fw4Nzz1NGleIH7lG0N5JAR
ZZi0qTVtqfO3kklc0unTKfKYttyonf2paWwca6iPuS3aHdQcANfQLavDqyQxqyii
UKX0HgbzpGS4Sol7fLZXwW7KLwQHCA==
=US/s
-END PGP SIGNATURE-

Bug#921687: systemctl just hangs on stoping or starting mysql-server-5.7

[Ansgar]

On Fri, 2019-02-08 at 00:35 +0100, Eduard Bloch wrote:
> So, out of blue my system cannot shutdown or reboot anymore. Hangs on 
> something with mysql.
> 
> So I tried to remove it since I don't need it here. Result: it fails to
> remove it, and just hangs there. I tried to update systemd, it's still
> ends in a frozen dpkg, doing deadlocking package configurations.
> 
> From user POV this is a disaster!

>From your process list and `systemctl status mysql` output, it looks
like the MySQL service has been trying to get stopped for 9min.  I
looked at the mysql.service file shipped in mysql-server-5.7_5.7.25-
1_amd64.deb and it sets a timeout of 10min:

+---
| TimeoutSec=600
+---[ mysql.service ]

I wonder if the process did continue if you wait a bit longer?

Besides that, I'm not sure systemd can do much differently here: it
just tries to follow the commands given, but mysql seems to not shut
down for some reason.

Could you include the processes related to mysql in your list?  Does
the mysql log include any hints what might be going wrong?

It might be more appropriate for this bug to be reassigned to the
mysql-server-5.7 package; I've included the maintainers in Cc as I
don't know much about MySQL and won't be much of a help here.

Ansgar

Bug#921712: Bug#921715: libgtk2.0-0-udeb: wrong dependency while building on buster based system

[Simon McVittie]

Control: reassign 921715 libxinerama1 1.1.4-1
Control: reassign 921712 libxinerama1 1.1.4-1
Control: merge 921715 921712
Control: severity 921715 serious
Control: affects 921715 + libgtk2.0-0-udeb

On Fri, 08 Feb 2019 at 09:27:20 +, Mayer, Dirk wrote:
> while building the gtk+2.0 source package on a buster based build system, the 
> resulting package libgtk2.0-0-udeb yields a wrong dependency.
> Instead of the correct dependency to the package libxinerama1-udeb it depends 
> on the wrong package libxinerama1.
> On the stretch based build system the dependency correctly refers to the udeb 
> package.

This seems to be a regression in libxinerama1 1.1.4-1. Its shlibs
metadata doesn't list a record for a udeb:

$ cat /var/lib/dpkg/info/libxinerama1:amd64.shlibs
libXinerama 1 libxinerama1

whereas other X11 udebs have an extra line for udebs, for example:

$ /var/lib/dpkg/info/libxcursor1:amd64.shlibs
libXcursor 1 libxcursor1 (>> 1.1.2)
udeb: libXcursor 1 libxcursor1-udeb (>> 1.1.2)

As a result, when gtk+2.0 is compiled, dh_shlibdeps doesn't know that
its udeb should depend on libxinerama1-udeb.

I think this is because the "--add-udeb=$(PACKAGE)-udeb" option wasn't
preserved during the rewrite of d/rules from traditional debhelper style
to dh.

I've raised this bug to serious severity, because I think it would break the
graphical installer next time gtk+2.0 is rebuilt (we've just been lucky that
the most recent gtk+2.0 upload was a few days before libxinerama1 1.1.4-1). The
X11 and d-i maintainers are of course welcome to reduce the severity if they
disagree with my assessment of its impact.

This probably also affects gtk+3.0, but I don't think debian-installer uses
that yet, so it's only a theoretical issue there.

> Duplicate to Bug #921712 because of wrong package tag
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921712

I've merged the bugs.

Thanks,
smcv

Bug#921704: tortoisehg: uninstallable with mercurial 4.9

[Julien Cristau]

Source: tortoisehg
Version: 4.8.1-0.1
Severity: serious
X-Debbugs-Cc: James Cowgill 

Hi,

mercurial 4.9 is now in sid, so tortoisehg needs an update.

Cheers,
Julien

Bug#921473: [deb...@kitterman.com: Bug#921473: calibre: Invalid maintainer address]

[Norbert Preining]

Hi Nicholas,

On Thu, 07 Feb 2019, Nicholas D Steeves wrote:
> was very unfortunate and could have been avoided by waiting until
> buster was released :-(

Indeed.

> going to be active in Debian for a while.  Is this email address now
> your preferred method of contact, or would you prefer using the gh

Yes, please. Actually all emails end up here, whereever you send them
but preining@d.o which is graciously broken.

Bugs should still go to the BTS, of course.

I just want to be sure that despite "interesting" decisions I can have
access to the repositories I maintain. Which is not the case on salsa.

> It would have been nice to have received notification of the new
> project location...but at any rate, for the purposes of reintegrating

Sorry, I posted a blog about it, but did not inform you personally. My
failure.

> Would you like to work on the integration or shall I?  No idea about

I will cum grano salis take over the master/upstream/pristine-tar branch
from your work, because this is what is in Debian uploaded.

For future work, I have added you to the collaborators of my
calibre-debian git, so you can pull/push directly to the github repo.

But please wait until I have updated the gh to match salsa, thanks.

> the pristine-tar branch, btw, because it should output an orig.tarball

No, as said, I will trash my stuff and use the orig you created.

> Also, at the moment are you able to dput the next upload of Calibre,
> or will I need to?

I can do that. I have DM rights for all my packages. I just couldn't
upload cssparser which I had packaged also already 2 months ago, but
wasn't able to upload since I am no DD.

Thanks for your understanding and help!

Norbert

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

Bug#911921: Bug ##911921: yubikey-manager new upstream version 1.0.1

[Felix Zielcke]

Am Donnerstag, den 07.02.2019, 22:29 +0100 schrieb Nicolas Braud-
Santoni:
> On Fri, Oct 26, 2018 at 09:17:32AM +0200, Felix Zielcke wrote:
> > Dear Maintainer,
> > 
> > please package the new upstream version 1.0.1 released by Yubico.
> > This adds support for the new Yubikey 5 series which I just bought.
> 
> Dear Felix,
> 
> Sorry for failing to notice your bug for so long.
> I have been struggling with health issues in the last half year, so
> the 
> maintainership of my packages suffered.  :(
> 
> I am uploading version 2.0.0 tonight, so you should enjoy support for
> your
> Yubikey 5 very soon!
> 
> 
> Best,
> 
>   nicoo

Hi Nicoo,

thanks very much for the upload. In the meanwhile I've used a
selfcompiled version.
Any chance that you could also package yubikey-manager-qt and update
(the much outdated) yubioath-desktop?
I thought about doing it myself, but I'm just a DM. So I would need a
sponsor. And for yubikey-manager-qt it's now too late anyway to get it
into buster.

Regards
Felix

Bug#921706: gnome: Please do not override debian-xterm.desktop

[Ben Wong]

Package: gnome
Version: 1:3.22+3
Severity: normal

Dear Maintainer,

When using the Gnome desktop, I cannot find the xterm icon by clicking
on Activities or by hitting the Super key and typing "xterm". I know
that I can run xterm by using Alt-F2, but that is not what I am
looking for.

Whenever I install Debian and use its default desktop, Gnome, it
always appears like xterm is missing. If I hit the Super key and type
in "term" I get these responses:

* Multilingual Terminal
* Thai X Terminal
* Terminal  [Presumably Gnome-Terminal]

If I type in "xterm", Gnome just says "Searching..." until I get tired
and cancel it.

However, xterm is installed and it even has a proper desktop entry in
/usr/share/applications/debian-xterm.desktop. I wasted way too much
time investigating why this didn't work, since it clearly should.

It turns out that some part of Gnome is creating a *second* desktop
file which disables the first one by setting NoDisplay = True. This is
extremely frustrating and unnecessary. The file is
/usr/share/gnome/applications/debian-xterm.desktop

I would like to tell you which part of Gnome is the culprit, but
`dpkg -S` on the file says it doesn't belong to any packages.

I can understand that certain distributions derived from Debian —
those which believe minimalism equates to simplicity — may wish to
hide "redundant" functionality like `xterm`. However, it doesn't make
sense to hide xterm from Debian users. And if it did, it certainly
should not be implemented in such a hard to discover way.

I request that Debian's Gnome stop overriding debian-xterm.desktop,
please.

Thank you.


P.S. Any distributions derived from Debian would of course be free to
create their own package which overrides debian-xterm.desktop. 
I suggest those distributions, instead of creating a second file,
create a package that runs

dpkg-divert --divert /usr/share/applications/debian-xterm.desktop.disabled \
--rename /usr/share/applications/debian-xterm.desktop

That way, they will have stopped xterm from cluttering their menus,
but in a way that might be more easily discoverable by users trying to
re-enable it.



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

Kernel: Linux 4.9.0-8-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)

Versions of packages gnome depends on:
ii  avahi-daemon 0.6.32-2
ii  cheese   3.22.1-1+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 9.0.2+deb9u1
ii  evolution3.22.6-1+deb9u1
ii  evolution-plugins3.22.6-1+deb9u1
ii  file-roller  3.22.3-1
ii  gedit-plugins3.22.0-1
ii  gimp 2.8.18-1+deb9u1
ii  gnome-calendar   3.22.4-2
ii  gnome-clocks 3.22.1-1
ii  gnome-color-manager  3.22.2-1
ii  gnome-core   1:3.22+3
ii  gnome-dictionary 3.20.0-3+b1
ii  gnome-documents  3.22.1-1
ii  gnome-getting-started-docs   3.22.0-1
ii  gnome-maps   3.22.2-1
ii  gnome-music  3.22.2-1
ii  gnome-orca   3.22.2-3
ii  gnome-screenshot 3.22.0-1+b1
ii  gnome-sound-recorder 3.21.92-2
ii  gnome-tweak-tool 3.22.0-1
ii  gnome-weather3.20.2-1
ii  gstreamer1.0-libav   1.10.4-1
ii  gstreamer1.0-plugins-ugly1.10.4-1
ii  inkscape 0.92.1-1
ii  libgsf-bin   1.14.41-1
ii  libgtk2-perl 2:1.2499-1
ii  libproxy1-plugin-networkmanager  0.4.14-2
ii  libreoffice-calc 1:5.2.7-1+deb9u4
ii  libreoffice-evolution1:5.2.7-1+deb9u4
ii  libreoffice-gnome1:5.2.7-1+deb9u4
ii  libreoffice-impress  1:5.2.7-1+deb9u4
ii  libreoffice-writer   1:5.2.7-1+deb9u4
ii  nautilus-sendto  3.8.4-2+b1
ii  network-manager-gnome1.4.4-1+deb9u1
ii  rhythmbox3.4.1-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.1-2+b1
ii  rhythmbox-plugins3.4.1-2+b1
ii  rygel-playbin0.32.1-3
ii  rygel-tracker0.32.1-3
ii  seahorse 3.20.0-3.1
ii  shotwell 0.25.4+really0.24.5-0.1
ii  simple-scan  3.23.2-1
ii  totem-plugins3.22.1-1
ii  vinagre  3.22.0-1+b1
ii  xdg-user-dirs-gtk0.10-1+b1

Versions of packages gnome recommends:
ii  brasero   3.12.1-4
ii  gnome-games   1:3.22+3
ii  polari

Bug#921711: libusrsctp1: typo in homepage

[Michael Becker]

Package: libusrsctp1
Version: 0.9.3.0+20190127-1
Severity: minor

Homepage is https://github.com/sctplib/usrsctp
but must be https://github.com/sctplab/usrsctp

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

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

Versions of packages libusrsctp1 depends on:
ii  libc6  2.28-5

libusrsctp1 recommends no packages.

libusrsctp1 suggests no packages.

Bug#921714: RM: python-xmp-toolkit -- RoQA; RC Buggy, unmaintained, dead upstream

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Dead due to lack of libexempi8 compatibility.

Scott K

Bug#921705: gnome: Please do not override debian-xterm.desktop file

[Ben Wong]

Package: gnome
Version: 1:3.22+3
Severity: normal

Dear Maintainer,

When using the Gnome desktop, I cannot find the xterm icon by clicking
on Activities or by hitting the Super key and typing "xterm". I know
that I can run xterm by using Alt-F2, but that is not what I am
looking for.

Whenever I install Debian and use its default desktop, Gnome, it
always appears like xterm is missing. If I hit the Super key and type
in "term" I get these responses:

* Multilingual Terminal
* Thai X Terminal
* Terminal  [Presumably Gnome-Terminal]

If I type in "xterm", Gnome just says "Searching..." until I get tired
and cancel it.

However, xterm is installed and it even has a proper desktop entry in
/usr/share/applications/debian-xterm.desktop. I wasted way too much
time investigating why this didn't work, since it clearly should.

It turns out that some part of Gnome is creating a *second* desktop
file which disables the first one by setting NoDisplay = True. This is
extremely frustrating and unnecessary. The file is
/usr/share/gnome/applications/debian-xterm.desktop

I would like to tell you which part of Gnome is the culprit, but
`dpkg -S` on the file says it doesn't belong to any packages.

I can understand that certain distributions derived from Debian —
those which believe minimalism equates to simplicity — may wish to
hide "redundant" functionality like `xterm`. However, it doesn't make
sense to hide xterm from Debian users. And if it did, it certainly
should not be implemented in such a hard to discover way.

I request that Debian's Gnome stop overriding debian-xterm.desktop,
please.

Thank you.


P.S. Any distributions derived from Debian would of course be free to
create their own package which overrides debian-xterm.desktop. 
I suggest those distributions, instead of creating a second file,
create a package that runs

dpkg-divert --divert /usr/share/applications/debian-xterm.desktop.disabled \
--rename /usr/share/applications/debian-xterm.desktop

That way, they will have stopped xterm from cluttering their menus,
but in a way that might be more easily discoverable by users trying to
re-enable it.



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

Kernel: Linux 4.9.0-8-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)

Versions of packages gnome depends on:
ii  avahi-daemon 0.6.32-2
ii  cheese   3.22.1-1+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 9.0.2+deb9u1
ii  evolution3.22.6-1+deb9u1
ii  evolution-plugins3.22.6-1+deb9u1
ii  file-roller  3.22.3-1
ii  gedit-plugins3.22.0-1
ii  gimp 2.8.18-1+deb9u1
ii  gnome-calendar   3.22.4-2
ii  gnome-clocks 3.22.1-1
ii  gnome-color-manager  3.22.2-1
ii  gnome-core   1:3.22+3
ii  gnome-dictionary 3.20.0-3+b1
ii  gnome-documents  3.22.1-1
ii  gnome-getting-started-docs   3.22.0-1
ii  gnome-maps   3.22.2-1
ii  gnome-music  3.22.2-1
ii  gnome-orca   3.22.2-3
ii  gnome-screenshot 3.22.0-1+b1
ii  gnome-sound-recorder 3.21.92-2
ii  gnome-tweak-tool 3.22.0-1
ii  gnome-weather3.20.2-1
ii  gstreamer1.0-libav   1.10.4-1
ii  gstreamer1.0-plugins-ugly1.10.4-1
ii  inkscape 0.92.1-1
ii  libgsf-bin   1.14.41-1
ii  libgtk2-perl 2:1.2499-1
ii  libproxy1-plugin-networkmanager  0.4.14-2
ii  libreoffice-calc 1:5.2.7-1+deb9u4
ii  libreoffice-evolution1:5.2.7-1+deb9u4
ii  libreoffice-gnome1:5.2.7-1+deb9u4
ii  libreoffice-impress  1:5.2.7-1+deb9u4
ii  libreoffice-writer   1:5.2.7-1+deb9u4
ii  nautilus-sendto  3.8.4-2+b1
ii  network-manager-gnome1.4.4-1+deb9u1
ii  rhythmbox3.4.1-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.1-2+b1
ii  rhythmbox-plugins3.4.1-2+b1
ii  rygel-playbin0.32.1-3
ii  rygel-tracker0.32.1-3
ii  seahorse 3.20.0-3.1
ii  shotwell 0.25.4+really0.24.5-0.1
ii  simple-scan  3.23.2-1
ii  totem-plugins3.22.1-1
ii  vinagre  3.22.0-1+b1
ii  xdg-user-dirs-gtk0.10-1+b1

Versions of packages gnome recommends:
ii  brasero   3.12.1-4
ii  gnome-games   1:3.22+3
ii  polari

Bug#921712: libgtk2.0-0-udeb: wrong dependency while building on buster based system

[Mayer, Dirk]

Source: libgtk2.0-0-udeb
Version: 2.24.32-3
Tags: d-i, buster

Hello Debian community,
while building the gtk+2.0 source package on a buster based build system, the 
resulting package libgtk2.0-0-udeb yields a wrong dependency.
Instead of the correct dependency to the package libxinerama1-udeb it depends 
on the wrong package libxinerama1.
On the stretch based build system the dependency correctly refers to the udeb 
package.

How to reproduce on a up-to-date buster based build system:
$ apt update
$ apt source gtk+2.0
$ cd gtk+2.0-2.24.32/
$ apt-get build-dep -y gtk+2.0
$ debuild -b -uc -us

Result:
$ dpkg --info ../libgtk2.0-0-udeb_2.24.32-3_amd64.udeb
new Debian package, version 2.0.
size 1680396 bytes: control archive=788 bytes.
1086 bytes,20 lines  control
 Package: libgtk2.0-0-udeb
 Source: gtk+2.0
 Version: 2.24.32-3
 Architecture: amd64
 Maintainer: Debian GNOME Maintainers 

 Installed-Size: 5099
 Depends: fontconfig-udeb (>= 2.13), libatk1.0-udeb (>= 2.30.0), 
libc6-udeb (>= 2.28), libcairo2-udeb (>= 1.14.0), libfreetype6-udeb (>= 2.9), 
libgdk-pixbuf2.0-0-udeb (>= 2.38.0+dfsg), libglib2.0-udeb (>= 2.58.2), 
libpango1.0-  udeb (>= 1.42.4), libx11-6-udeb (>= 2:1.6.0), 
libxcursor1-udeb (>> 1.1.2), libxext6-udeb (>= 2:1.3.0), libxi6-udeb (>= 
2:1.6.99.1), libxinerama1, libxrender1-udeb
 Provides: gtk2.0-binver-2.10.0
 Section: debian-installer


Expected result: 
$ dpkg --info ../libgtk2.0-0-udeb_2.24.32-3_amd64.udeb
new Debian package, version 2.0.
size 1680396 bytes: control archive=788 bytes.
1086 bytes,20 lines  control
 Package: libgtk2.0-0-udeb
 Source: gtk+2.0
 Version: 2.24.32-3
 Architecture: amd64
 Maintainer: Debian GNOME Maintainers 

 Installed-Size: 5099
 Depends: fontconfig-udeb (>= 2.13), libatk1.0-udeb (>= 2.30.0), 
libc6-udeb (>= 2.28), libcairo2-udeb (>= 1.14.0), libfreetype6-udeb (>= 2.9), 
libgdk-pixbuf2.0-0-udeb (>= 2.38.0+dfsg), libglib2.0-udeb (>= 2.58.2), 
libpango1.0-  udeb (>= 1.42.4), libx11-6-udeb (>= 2:1.6.0), 
libxcursor1-udeb (>> 1.1.2), libxext6-udeb (>= 2:1.3.0), libxi6-udeb (>= 
2:1.6.99.1), libxinerama1-udeb, libxrender1-udeb
 Provides: gtk2.0-binver-2.10.0
 Section: debian-installer

$ uname -a
Linux buster 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 
GNU/Linux

$ cat /etc/debian_version
buster/sid


Thanks.

Dirk Mayer

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Roman Mamedov]

On Fri, 8 Feb 2019 10:42:06 +0100
Aurelien Jarno  wrote:

> Yes, that's normal that only LANG is set, as it's the one with less
> priority. That said there was clearly something setting LC_ALL to
> en.US-UTF-8 before, you might want to grep /etc for that. When only LANG
> is set, you should get and output like this one:

Thanks, turns out in my case the "culprit" was LC_ALL getting passed from the
ssh client each time, due to /etc/ssh/sshd_config:

  # Allow client to pass locale environment variables
  AcceptEnv LANG LC_*

-- 
With respect,
Roman

Bug#821405: dhcpcd no longer starts wpa_supplicant

[Scott Leggett]

Hi Juliusz,

Can you confirm if Roy's solution works for you in Buster?

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Aurelien Jarno]

On 2019-02-07 14:55, Roman Mamedov wrote:
> So for those of us (the entire world), who have been relying on this behavior:
> 
> > * en_US (.UTF-8) is used as the default English locale for all places that
> >   don't have a specific variant (and often even then).  Generally, technical
> >   users use English as a system locale

Please note that the en_US.UTF-8 locale had the 12-hour time for more
than 20 years, for all applications but the date utility. Therefore this
locale was not a reliable way to get a 24-hour time format.

> How do we roll-back what you have done here, and still get en_US.UTF-8 while
> retaining the proper 24-hour time?
> 
> dpkg-reconfigure locales does not list "C.UTF-8" in the main "locales to
> generate" list, but does offer it on the next screen as "Default locale for 
> the
> system environment". After selecting it, we get:
> 
> # locale
> LANG=C.UTF-8
> LANGUAGE=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=en_US.UTF-8

What is the content of /etc/default/locale? it looks like you have an
additional entry than the LANG one set by dpkg-reconfigure locales.

Also note that you can edit that file and chose a different locale for
each entry, so you can have for example a POSIX way of representing the
time, using a Turkish collation and with a Chilean monetary symbol.

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

Bug#921713: Clarification needed in /etc/default/libvirtd

[Petter Adsen]

Package: libvirt-daemon-system
Version: 5.0.0-1

In /etc/default/libvirtd there is the following content:

# options passed to libvirtd, add "-l" to listen on tcp
#libvirtd_opts=""

If the latter line is uncommented and -l is added, libvirtd fails to
start because it does not have a certificate. The log message that
informs the user of this is kind of non-obvious, and not visible in
'systemctl status libvirtd' output. Would it be possible to add a short
note that a certificate must be added to use -l?

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Roman Mamedov]

On Fri, 8 Feb 2019 10:21:41 +0100
Aurelien Jarno  wrote:

> What is the content of /etc/default/locale? it looks like you have an
> additional entry than the LANG one set by dpkg-reconfigure locales.

"dpkg-reconfigure locales" only writes LANG=C.UTF-8 (or any other accordingly)
to that file. This results in the "locale" output that I posted above
(including after a relogin or reboot). There were no lines aside from that
in /etc/default/locale.

I was able to get the desired result only by manually adding a line with
"LC_ALL=C.UTF-8" to /etc/default/locale.

# locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=C.UTF-8

It is puzzling why this is required.

-- 
With respect,
Roman

Bug#921715: libgtk2.0-0-udeb: wrong dependency while building on buster based system

[Mayer, Dirk]

Package: gtk+2.0
Version: 2.24.32-3
Tags: d-i, buster

Hello Debian community,
while building the gtk+2.0 source package on a buster based build system, the 
resulting package libgtk2.0-0-udeb yields a wrong dependency.
Instead of the correct dependency to the package libxinerama1-udeb it depends 
on the wrong package libxinerama1.
On the stretch based build system the dependency correctly refers to the udeb 
package.

How to reproduce on a up-to-date buster based build system:
$ apt update
$ apt source gtk+2.0
$ cd gtk+2.0-2.24.32/
$ apt-get build-dep -y gtk+2.0
$ debuild -b -uc -us

Result:
$ dpkg --info ../libgtk2.0-0-udeb_2.24.32-3_amd64.udeb
new Debian package, version 2.0.
size 1680396 bytes: control archive=788 bytes.
1086 bytes,20 lines  control
 Package: libgtk2.0-0-udeb
 Source: gtk+2.0
 Version: 2.24.32-3
 Architecture: amd64
 Maintainer: Debian GNOME Maintainers 

 Installed-Size: 5099
 Depends: fontconfig-udeb (>= 2.13), libatk1.0-udeb (>= 2.30.0), 
libc6-udeb (>= 2.28), libcairo2-udeb (>= 1.14.0), libfreetype6-udeb (>= 2.9), 
libgdk-pixbuf2.0-0-udeb (>= 2.38.0+dfsg), libglib2.0-udeb (>= 2.58.2), 
libpango1.0-  udeb (>= 1.42.4), libx11-6-udeb (>= 2:1.6.0), 
libxcursor1-udeb (>> 1.1.2), libxext6-udeb (>= 2:1.3.0), libxi6-udeb (>= 
2:1.6.99.1), libxinerama1, libxrender1-udeb
 Provides: gtk2.0-binver-2.10.0
 Section: debian-installer


Expected result: 
$ dpkg --info ../libgtk2.0-0-udeb_2.24.32-3_amd64.udeb
new Debian package, version 2.0.
size 1680396 bytes: control archive=788 bytes.
1086 bytes,20 lines  control
 Package: libgtk2.0-0-udeb
 Source: gtk+2.0
 Version: 2.24.32-3
 Architecture: amd64
 Maintainer: Debian GNOME Maintainers 

 Installed-Size: 5099
 Depends: fontconfig-udeb (>= 2.13), libatk1.0-udeb (>= 2.30.0), 
libc6-udeb (>= 2.28), libcairo2-udeb (>= 1.14.0), libfreetype6-udeb (>= 2.9), 
libgdk-pixbuf2.0-0-udeb (>= 2.38.0+dfsg), libglib2.0-udeb (>= 2.58.2), 
libpango1.0-  udeb (>= 1.42.4), libx11-6-udeb (>= 2:1.6.0), 
libxcursor1-udeb (>> 1.1.2), libxext6-udeb (>= 2:1.3.0), libxi6-udeb (>= 
2:1.6.99.1), libxinerama1-udeb, libxrender1-udeb
 Provides: gtk2.0-binver-2.10.0
 Section: debian-installer

$ uname -a
Linux buster 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 
GNU/Linux

$ cat /etc/debian_version
buster/sid


Duplicate to Bug #921712 because of wrong package tag
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921712


Thanks.

Dirk Mayer

Bug#921685: 1.8.0~rc2 breaks using Release.gpg instead of InRelease

[David Kalnischkies]

Hi,

On Thu, Feb 07, 2019 at 04:54:01PM -0500, Anthony DeRobertis wrote:
> We have a local repository here which is generated with an (ancient!)
> version of mini-dinstall. This worked fine until rc2. The problem
> appears to be that it uses Release and Release.gpg instead of InRelease.

~rc1 adds verification of the contents of the "Release.gpg" file to
ensure the file can't be used to sneak additional data to the disk gpgv
ignores but could later be used in exploits – this was part of the
exploit for CVE-2019-3462.


> Get:3 http://haruhi.metrics.net/deb buster/ Release.gpg [88 B]

That is some very small file given that ~60 B of the file are
boilerplate due to ascii armored headers and such… So, is that file
actually an ascii armored detached signature?  Could you attach it?

apt-secure(8) always documented "gpg -abs -o Release.gpg Release" as the
call to generate a Release.gpg file, but if you omit the "a" you still
get a Release.gpg file gpgv happily accepts – in a binary format.


The new verification code expects the documented ascii armored detached
signature here and as it can't find any valid part of it assumes bad
data was sent by something like a webportal from a hotel wifi – hence
the message about NODATA and net-auth.


That could be considered a regression, but I don't think we should add
support in the file-content verification for the binary format as that
is just additional code and risks with very minimal benefit attached.
I am inclined to declare this a user error due to not following
documentation. It is also resolveable with literally one additional
character on repository-creator side…

So if nobody has a strong opinion to the contrary I will look at using
a different (untranslated) message if a binary signature is encountered
at most to resolve this bugreport – assuming my conclusion holds that
this is indeed due to a binary signature and that they can reasonably be
detected.

Disclaimer: I wrote the code refusing the file, so I might be biased.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#921716: ITP: icingaweb2-module-ipl -- icingaweb2 php library

[Kunz David]

Package: wnpp
Owner: david.k...@dknet.ch

* Package name: icingaweb2-module-ipl
  Upstream Author : Icinga Development Team 
* License : 
  Description : new php library for icingaweb2

  Icinga Web 2 is a very modular, fast and simple web interface for 
  your Icinga monitoring environment.
  .
  New PHP library for Icinga Web 2

Greetings,
David

Bug#818880: dhcpcd5: sometimes removes route to local network on wakeup

[Scott Leggett]

Hi,

Thanks for the report.
I haven't seen this issue, so its difficult to debug..

Could you try using the latest package in testing to see if it improves
things for you?

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#921117: stretch-pu: package debian-security-support/2019.02.01~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2019-02-01 18:31, Antoine Beaupre wrote:

I'd like to update debian-security-support in Stretch to synchronize
with the other suites. I expect this should go in via a normal point
update, as per previous request in #915715.

This has already been uploaded to stretch and released as part of
DLA-1657-1:

https://lists.debian.org/debian-lts-announce/2019/02/msg2.html


ITYM jessie. :-)


The diff is as follows. It is similar to the unstable package, except
for debhelper-compat, which would require backports, and standards
bump, which seem superfluous.


Please go ahead, bearing in mind that the window for 9.8 closes this 
weekend.


Regards,

Adam

Bug#921620: stretch-pu: package debian-edu-config/1.929+deb9u2

[Holger Levsen]

On Fri, Feb 08, 2019 at 12:44:51PM +, Adam D. Barratt wrote:
> > we would like to update debian-edu-config in stretch with the following
> Please go ahead, bearing in mind that the window for 9.8 closes this
> weekend.

thanks, uploaded.


-- 
tschau,
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#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Egmont Koblinger]

Hi,

> Yes, but my point is that the default should not be broken.

One could argue that the wheels working in "less" (or any other
similar app) is the expected behavior, and not working at all is the
broken one...

I think we just have to agree that we disagree.


cheers,
egmont

Bug#921711: libusrsctp1: typo in homepage

[Michael Becker]

Hi Jonas,

that completely addresses my concerns.

Thanks: Michael



On 08.02.19 14:04, Jonas Smedegaard wrote:
> [ reply via bugreport ]
> 
> Hi Michael,
> 
> Quoting Michael Becker (2019-02-08 12:34:05)
>> please apply the fix for all packages belonging to sctplib.
> 
> Fix was applied to the packaging _source_ and will reflect all binary 
> packages built from that same source: 
> https://salsa.debian.org/pkg-voip-team/libusrsctp/commit/697f092
> 
> Does that sound like it addresses your concern here, or did you mean to 
> raise a different issue/concern?
> 
> 
>  - Jonas
> 



signature.asc
Description: OpenPGP digital signature

Bug#921730: iptables-restore: not found on Stretch to Buster upgrade

[Herman van Rink]

Package: netfilter-persistent
Version: 1.0.10
Severity: normal

Dear Maintainer,

While upgrading a test vm from Stretch to Buster I got the error
'iptables-restore: not found'. from the netfilter-persistent package.

I suspect that this relates to moving that binary from /sbin to
/usr/sbin in the iptables 1.8.1-2 package.

Starting dist-upgrade again finishes without errors.

On review I see that the iptables packages created a symlink for
compatibility, but the modification timestamp is a few seconds after the
log messages shown below. Race condition?


Feb 08 14:07:04 debian systemd[1]: Starting netfilter persistent
configuration...
Feb 08 14:07:04 debian netfilter-persistent[24920]: run-parts: executing
/usr/share/netfilter-persistent/plugins.d/15-ip4tables start
Feb 08 14:07:04 debian netfilter-persistent[24920]:
/usr/share/netfilter-persistent/plugins.d/15-ip4tables: 23:
/usr/share/netfilter-persistent/plugins.d/15-ip4tables:
iptables-restore: not found
Feb 08 14:07:04 debian netfilter-persistent[24920]: run-parts:
/usr/share/netfilter-persistent/plugins.d/15-ip4tables exited with
return code 127
Feb 08 14:07:04 debian netfilter-persistent[24920]: run-parts: executing
/usr/share/netfilter-persistent/plugins.d/25-ip6tables start
Feb 08 14:07:04 debian netfilter-persistent[24920]:
/usr/share/netfilter-persistent/plugins.d/25-ip6tables: 26:
/usr/share/netfilter-persistent/plugins.d/25-ip6tables:
ip6tables-restore: not found
Feb 08 14:07:04 debian netfilter-persistent[24920]: run-parts:
/usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with
return code 127
Feb 08 14:07:04 debian systemd[1]: netfilter-persistent.service: Main
process exited, code=exited, status=1/FAILURE
Feb 08 14:07:04 debian systemd[1]: netfilter-persistent.service: Failed
with result 'exit-code'.
Feb 08 14:07:04 debian systemd[1]: Failed to start netfilter persistent
configuration.
dpkg: error processing package netfilter-persistent (--configure):
 installed netfilter-persistent package post-installation script
subprocess returned error exit status 1



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

Kernel: Linux 4.19.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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages netfilter-persistent depends on:
ii  lsb-base  10.2018112800

netfilter-persistent recommends no packages.

Versions of packages netfilter-persistent suggests:
ii  iptables-persistent  1.0.10

-- no debconf information


-- 

Met vriendelijke groet / Regards,

Herman van Rink
Initfour websolutions




signature.asc
Description: OpenPGP digital signature

Bug#917456: urgent need to upgrade upstream

[PICCORO McKAY Lenz]

https://github.com/sippy/rtpproxy/releases

please men! what it's so hard to find?

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

El vie., 8 de feb. de 2019 a la(s) 02:45, Geert Stappers
(stapp...@stappers.nl) escribió:
>
> Control: severity -1 normal
> Thanks
>
> Not everyone is in need for NAT tricks.
>
> But if I understand the bugreport submitter correctly,
> then is this report about a new version.
>
> https://tracker.debian.org/pkg/rtpproxy shows
> that checking for new update version is broken.
>
>
> What would help is reporting where the new upstream version
> can be found.
>
>
> Cheers
> Geert Stappers
> --
> The proper way to break the unwritten agreement
> of "Someone else should do it"
> is doing what should be done.

Bug#921685: 1.8.0~rc2 breaks using Release.gpg instead of InRelease

[Anthony DeRobertis]

Ah, that's it. It's a binary detached signature. I probably missed the 
documentation when it was originally set up (or maybe it hasn't always been 
documented well, it was originally set up a decade ago).

I'll fix the signature generation later today and confirm.

I don't see a problem with dropping support for binary signatures, at least 
with a better error message and maybe it deserves a release note.

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

On 2019-02-08 15:21:00 +0100, Egmont Koblinger wrote:
> > Perhaps it should have generated scroll-backward (kR) and
> > scroll-forward (kF) keys, and provided a terminfo that defines
> > them. That way, this wouldn't mix up with the  and 
> > keys.
> 
> There would be no point in that either: if an application cares enough
> to handle kR and kF, it could just as easily handle mouse scroll
> events directly.

No, because handling mouse scroll events needs special support in
the application, while handling kR and kF just needs a small change
of configuration (basically, adding a key binding).

> Again, the point of this feature, which you disagree with, was to make
> it _automatic_ (even despite its drawbacks in some contexts) for apps
> that don't care enough.

Handling kR and kF can be automatic: just ask either upstream or
downstream to change the default configuration. This is easy to do,
and all users would benefit from this change, with no drawbacks.

> (And, on a totally irrelevant note, which has been discussed many
> times and I won't start over, gnome-terminal doesn't ship its separate
> terminfo but piggybacks xterm's.)

That is its own problem. But note that the xterm-based terminfo data
could also add such keys.

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

Bug#921340: RM: olive/20181223-1

[Emilio Pozuelo Monfort]

Control: tags -1 moreinfo

On 04/02/2019 13:08, Gürkan Myczko wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> (explain the reason for the removal here)

You were supposed to replace that by an explanation.

Emilio

Bug#921538: Fails to start since upgrade to 1.9.0-1

[Kepi]

Chroot workaround is working for me too. It should probably be uploaded
as soon as possible to save more networks :)

Anyway in the long term would it be better to have chroot setup
automatically again? I found out that it was working before, at least
some work was done in #579622 for auto support.

Cheers

-- 
Kepi


signature.asc
Description: PGP signature

Bug#921722: Please stop making libraries recommending qpdf

[Laurent Bigonville]

Source: qpdf
Version: 8.4.0-1
Severity: normal

Hi,

Are there any reasons why the libqpdf Recommends qpdf? Does the library
use an executable contained in that package?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

-- no debconf information

Bug#908960: stretch-pu: package rtkit/0.11-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2018-09-16 19:59, Adrian Bunk wrote:

* Move dbus and polkit from Recommends to Depends
  rtkit can't do much really without either of them so bump them to 
Depends.

  (Closes: #881342)

Read #881342 if you are interested in the nasty details of
what can happen without them.


Please go ahead; apologies for the long delay.

Regards,

Adam

Bug#921725: libu2f-host: CVE-2018-20340

[Salvatore Bonaccorso]

Source: libu2f-host
Version: 1.1.2-2
Severity: grave
Tags: security upstream
Control: found -1  1.1.6-1

Hi,

The following vulnerability was published for libu2f-host.

CVE-2018-20340[0]:
buffer overflow

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-20340
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20340
[1] https://www.yubico.com/support/security-advisories/ysa-2019-01/

Regards,
Salvatore

Bug#921726: libu2f-host: CVE-2018-20340

[Sébastien Delafond]

Package: libu2f-host
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for libu2f-host.

CVE-2018-20340[0]:
Unchecked buffer in libu2f-host before 1.1.7 ...

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

Please adjust the affected versions in the BTS as needed.

Bug#921703: Seems gem2deb itself is broken

[Pirate Praveen]

Control: severity -1 grave

gem2deb compass-rails also failed with same error. Marking grave as core 
functionality itself is broken.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#921538: Fails to start since upgrade to 1.9.0-1

[Simon Deziel]

On 2019-02-08 7:26 a.m., Kepi wrote:
> Chroot workaround is working for me too.

Good.

> Anyway in the long term would it be better to have chroot setup
> automatically again? I found out that it was working before, at least
> some work was done in #579622 for auto support.

The auto-chroot setup was broken with the (welcomed) move to systemd
notify. I have a working PoC to restore the functionality that I'll
submit soon as another merge request.

Regards,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Egmont Koblinger]

Hi,

> Perhaps it should have generated scroll-backward (kR) and
> scroll-forward (kF) keys, and provided a terminfo that defines
> them. That way, this wouldn't mix up with the  and 
> keys.

There would be no point in that either: if an application cares enough
to handle kR and kF, it could just as easily handle mouse scroll
events directly.

Again, the point of this feature, which you disagree with, was to make
it _automatic_ (even despite its drawbacks in some contexts) for apps
that don't care enough.

(And, on a totally irrelevant note, which has been discussed many
times and I won't start over, gnome-terminal doesn't ship its separate
terminfo but piggybacks xterm's.)

While the feature isn't perfect (it cannot be due to its nature), it's
arguably still more useful for many people than harmful. I've seen
many more people complaining about its lack whenever it didn't work
for them, than complaining about its problems and imperfectness. If
you find it harmful, you can switch it off.


cheers,
egmont

Bug#921340: RM: olive/20181223-1

[Gürkan Myczko]

Ah sorry, the explanation would be,
I hijacked olive, it's now it properly as olive-editor,
and olive in testing/sid can be removed, and then
#920799 can be closed.

Best,

On 08.02.2019 13:13, Emilio Pozuelo Monfort wrote:

Control: tags -1 moreinfo

On 04/02/2019 13:08, Gürkan Myczko wrote:

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

(explain the reason for the removal here)


You were supposed to replace that by an explanation.

Emilio

Bug#511408: sparse: -E -MF doesn't work

[Luc Van Oostenryck]

Hi,

Improvements are possible in this area but
cgcc -E test.c -o test.C -MF test.d
is not supposed to work as expected by OP since
gcc -E test.c -o test.C -MF test.d
is not working.

So, it's not a bug and this PR should be closed.

Best regards,
-- Luc Van Oostenryck

Bug#921340: RM: olive/20181223-1

[Emilio Pozuelo Monfort]

Control: reassign -1 ftp.debian.org

On 08/02/2019 13:28, Gürkan Myczko wrote:
> Ah sorry, the explanation would be,
> I hijacked olive, it's now it properly as olive-editor,
> and olive in testing/sid can be removed, and then
> #920799 can be closed.

Removals from sid need a bug against the ftp team, reassigning. Removal from
testing will follow automatically once the package is removed from sid.

BTW, I don't know why you renamed the package, but you probably want to keep an
olive binary as a transitional package.

Emilio

Bug#921727: msxpertsuite: FTBFS when built with dpkg-buildpackage -A (debian/build/doc: No such file or directory)

[Santiago Vila]

Package: src:msxpertsuite
Version: 5.8.2-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid with "dpkg-buildpackage -A" but it failed:


[...]
 debian/rules build-indep
PATH: 
/<>/doc/user-manuals/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
"---"
NUMJOBS: 1
MAKEFLAGS:  -j1
DEB_BUILD_OPTIONS: parallel=1
"---"
dh_testdir -i
dh_prep -i
rm -f -- debian/msxpertsuite-massxpert-data-doc.substvars 
debian/msxpertsuite-minexpert-data-doc.substvars
rm -fr -- debian/.debhelper/generated/msxpertsuite-massxpert-data-doc/ 
debian/msxpertsuite-massxpert-data-doc/ debian/tmp/ 
debian/.debhelper/generated/msxpertsuite-minexpert-data-doc/ 
debian/msxpertsuite-minexpert-data-doc/
rm -rf /<>/debian/tmp-indep
mkdir -p /<>/debian/build
cd doc/user-manuals/massxpert && \

[... snipped ...]

   File 'copy_static_images_html' does not exist.
Must remake target 
'/<>/doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual/static'.
mkdir -p 
/<>/doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual/static
Successfully remade target file 
'/<>/doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual/static'.
  Must remake target 'copy_static_images_html'.
tar cph --exclude-vcs -C /<>/doc/user-manuals/xslt/ static | \
  (cd 
/<>/doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual;
 tar xpv) >/dev/null
  Successfully remade target file 'copy_static_images_html'.
Must remake target 'html'.
HTML book built with REMARKS=0, DRAFT=no and META=0:
/<>/doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual/
Successfully remade target file 'html'.
make[2]: Leaving directory '/<>/doc/user-manuals/minexpert'
make[1]: Leaving directory '/<>/doc/user-manuals/minexpert'
# Copythe default-named pdf file to what we want
cp -fv 
doc/user-manuals/minexpert/build/minexpert-user-manual/minexpert-user-manual_color_en.pdf
 doc/user-manuals/minexpert/build/minexpert-user-manual/minexpert-doc.pdf
'doc/user-manuals/minexpert/build/minexpert-user-manual/minexpert-user-manual_color_en.pdf'
 -> 'doc/user-manuals/minexpert/build/minexpert-user-manual/minexpert-doc.pdf'
# Remove libjs-jquery from both massxpert and minexpert html user manuals
# build directory and later replace them with symbolic links to the same file
# of the libjs-jquery package (see the debian/*links files for the doc
# packages).
rm -f 
doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual/static/js/jquery-1.10.2.min.js
rm -f 
doc/user-manuals/massxpert/build/massxpert-user-manual/html/massxpert-user-manual/static/js/jquery-1.10.2.min.js
rm -f 
doc/user-manuals/minexpert/build/minexpert-user-manual/html/minexpert-user-manual/static/js/highlight.min.js
rm -f 
doc/user-manuals/massxpert/build/massxpert-user-manual/html/massxpert-user-manual/static/js/highlight.min.js
touch build-indep-stamp
 fakeroot debian/rules binary-indep
PATH: 
/<>/doc/user-manuals/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
"---"
NUMJOBS: 1
MAKEFLAGS:  -j1
DEB_BUILD_OPTIONS: parallel=1
"---"
dh_testdir -i
dh_testroot -i
dh_installdirs -i
install -d debian/msxpertsuite-massxpert-data-doc
install -d 
debian/msxpertsuite-massxpert-data-doc/usr/share/msxpertsuite-massxpert/data 
debian/msxpertsuite-massxpert-data-doc/usr/share/msxpertsuite-massxpert/doc 
debian/msxpertsuite-massxpert-data-doc/usr/share/msxpertsuite-massxpert/doc/html
install -d debian/msxpertsuite-minexpert-data-doc
install -d 
debian/msxpertsuite-minexpert-data-doc/usr/share/doc/msxpertsuite-minexpert/doc 
debian/msxpertsuite-minexpert-data-doc/usr/share/msxpertsuite-minexpert/doc/html
mkdir -p /<>/debian/tmp-indep
/usr/bin/make -C /<>/debian/build/doc install 
DESTDIR=/<>/debian/tmp-indep
make[1]: *** /<>/debian/build/doc: No such file or directory.  
Stop.
make: *** [debian/rules:148: install-indep-stamp] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


To reproduce, please try "dpkg-buildpackage -A".

Usually, splitting override_dh_foo into override_dh_foo-arch and 
override_dh_foo-indep
helps a lot to solve these kind of problems, but I'm afraid that will not help 
here
unless debian/rules is converted to use "dh" first.

While we are at it, please consider uploading in source-only form 
(dpkg-buildpackage -S).
This would provide official build logs in buildd.debian.org and also helps 
these kind
of bugs to never propagate to testing.

Thanks.

Bug#921572: mercurial breaks hg-git autopkgtest: ProgrammingError: callcommand() cannot be used after commands are sent

[Julien Cristau]

Control: severity -1 serious
Control: clone -1 -2
Control: reassign -1 mercurial 4.9-1
Control: retitle -1 mercurial: needs Breaks on hg-git <= 0.8.12-1
Control: reassign -2 hg-git 0.8.12-1
Control: retitle -2 hg-git: incompatible with mercurial 4.9

On 2/6/19 9:41 PM, Paul Gevers wrote:
> With a recent upload of mercurial the autopkgtest of hg-git fails in
> testing when that autopkgtest is run with the binary packages of
> mercurial from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> mercurial  from testing4.9-1
> hg-git from testing0.8.12-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. There are lots
> of deprecation warnings that hg-git must fix one way or the other (for
> real, or in the reference data), but there are other failures that I am
> not sure about. Please check the full log.
> 
> Currently this regression is blocking the migration of mercurial to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
> 
Guess there's two parts here, splitting them.  hg-git has been in need
of upstream love for a while AFAICT...

Cheers,
Julien

Bug#775464: ITP: linsim -- Amateur Radio Digital Mode Evaluation Tool

[Christoph Berg]

Control: tag -1 moreinfo

Re: ki7mt 2015-01-16 <54b84784.2080...@yahoo.com>
> Package: wnpp
> Severity: wishlist
> Owner: Greg Beam 
> 
> * Package name: linsim
>   Version : 2.0.0
>   Upstream Author : Dave Freese
> * URL : http://www.w1hkj.com/
> * License : (GPL-3)
>   Programming Lang: (C, C++)
>   Description : Amateur Radio Digital Mode Evaluation Tool
> 
> Linsim is a computer program intended as a tool for Amateur Radio
> Digital Mode evaluation under varying HF propagation conditions.
> 
> -Density variations versus altitude in the ionosphere
> -Magnetic-ionic effects that cause polarization-dependent paths
> -Non-uniformity of the ionospheric layers

Hi Greg,

there seems to be a ready package in git, but it was never uploaded:

https://salsa.debian.org/debian-hamradio-team/linsim

Does packaging it still make sense? Do you still intend to maintain it?

Christoph

Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text

[Andrius Merkys]

On 2019-02-08 04:08, Mo Zhou wrote:
> Is this package useful enough without these components?

I would say so. opennlp-tools is the core toolkit of the OpenNLP, while 
opennlp-brat-annotator and opennlp-morfologik-addon are merely add-ons to other 
software packages. Furthermore, language parsing and language detection 
examples execute successfully after having all binary packages installed, both 
using the CLI and Java compiler. Therefore, I assume that core functionality 
works as would be expected.

Best wishes,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#921720: nmu: why3_1.1.1-4

[Ralf Treinen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: Benjamin Barenblat 

nmu why3_1.1.1-4 . armhf . unstable . -m "rebuild against coq 8.9.0"

this blocks migration of why3 1.1.1-4 to testing.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 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

Bug#921643: stretch-pu: package libemail-address-list-perl/0.05-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2019-02-07 15:28, Dominic Hargreaves wrote:

Fixes CVE-2018-18898 which is exposed by request-tracker4.
Candidate package deployed and working so far on a production system.


Please go ahead, bearing in mind that the window for 9.8 closes this 
weekend.


Regards,

Adam

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Wouter Verhelst]

On Thu, Feb 07, 2019 at 02:05:33PM +0100, Adam Borowski wrote:
> > LC_TIME="en_US.UTF-8"

If you don't want US time, don't set US time.

Instead, do something like:

LC_TIME=en_BE.UTF-8

which means "I want time in English, but using Belgian customs, not the
US ones".

You may have to custom edit that time definition, though. Alternatively,
set LC_TIME to en_GB.UTF-8 or whatever other pre-existing locale.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#921729: olive-editor: In appropriate conflicts/replaces

[Scott Kitterman]

Package: olive-editor
Version: 20181223-1
Severity: important

Once the currently requested removal of src:olive is done, and olive-editor is
in testing, the conflicts/replaces should be dropped as olive-editor does not
conflict nor replace the old olive package that is in stable.

Scott K

Bug#859122: about 500 DLAs missing from the website

[Holger Levsen]

Hi Antoine,

On Sun, Feb 03, 2019 at 02:08:06PM +0100, Salvatore Bonaccorso wrote:
> Thanks for working on this.

indeed!

> On Fri, Feb 01, 2019 at 01:44:10PM -0500, Antoine Beaupré wrote:
> > On 2018-12-19 18:05:36, Antoine Beaupré wrote:
> > > The DLAs are visible here:
> > > https://www-staging.debian.org/security/2018/dla-1580

that one is also visible on
https://www.debian.org/security/2018/dla-1580 now \o/

> > > One thing that's unclear is how the entries get added to the main list
> > > in:
> > > https://www-staging.debian.org/security/2018/
> IMHO they should not be mixed into the same namespace as the DSAs.
> https://www.debian.org/security/ is very specific to the
> debian-security-announce list and contains items for e.g. contacting
> the Debian security team or referecing the respective FAQ.
 
I agree.

(Thus I think
https://salsa.debian.org/webmaster-team/webwml/merge_requests/50 should
be cloded and not merged.)

OTOH I plan to review
https://salsa.debian.org/webmaster-team/webwml/merge_requests/53 once
more and then merge it.)

> I think having a dedicated https://www.debian.org/lts/ where those can
> be collected and having further information on LTS would be somehow
> better.

Yup.

> This will need an adjustment to the tracker side as well so that
> sources filed for Debian LTS DLA's will not link to
> https://www.debian.org/security/$year/dla-$nr .

*nods*

> If a dedicated subpage is not needed and the only purpose is to link
> to a webversion, and the DLA's do not show up in the overall view then
> possibly the status quo is still okay.

I think it's ok for now / the current situation is an improvement over
what we had before, but we really want/need one a dedicated page like
https://www.debian.org/lts/ too.


On Sun, Feb 03, 2019 at 02:38:02PM +0100, Laura Arjona Reina wrote:
> Note that we already have some DLAs published in
> www.debian.org/security/, for the years 2014, 2015 and 2016. See
> for
> example:
> 
> https://www.debian.org/security/2014/index
> 
> I don't mind to move the already published DLAs to other place if
> people
> decides it's better, but I frankly don't know if/where these URLs are
> used/publicised (in Debian and maybe other places too), and we may
> need
> to setup redirectors from the current URLs to the new ones (no problem
> with that, I say it only to not forget, in case we decide to move all
> the DLAs to a different place).

right. we should do that and probably track this with a bug...


-- 
tschau,
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#921522: prometheus: promtool does not have an update command (?)

[Santiago Vila]

> > Maybe this feature could be backported from the backport to the
> > version in buster? :-)
> 
> So I checked with upstream, they decided to remove it because for them
> it is already obsolete.. I will try to backport this, but it could be
> tricky as the codebase has evolved since this was removed.

If that becomes very tricky, another option would be to upload the
current version in stretch-backports with the name prometheus-promtool
and essentially remove everything but /usr/bin/promtool from the .deb.

Thanks.

Bug#921620: stretch-pu: package debian-edu-config/1.929+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2019-02-07 11:16, Holger Levsen wrote:

we would like to update debian-edu-config in stretch with the following
changes (with the distribution set to stretch obviously), which are all
available in buster since several months:


Please go ahead, bearing in mind that the window for 9.8 closes this 
weekend.


Regards,

Adam

Bug#921711: libusrsctp1: typo in homepage

[Jonas Smedegaard]

[ reply via bugreport ]

Hi Michael,

Quoting Michael Becker (2019-02-08 12:34:05)
> please apply the fix for all packages belonging to sctplib.

Fix was applied to the packaging _source_ and will reflect all binary 
packages built from that same source: 
https://salsa.debian.org/pkg-voip-team/libusrsctp/commit/697f092

Does that sound like it addresses your concern here, or did you mean to 
raise a different issue/concern?


 - Jonas

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

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


signature.asc
Description: signature

Bug#921728: olive-editor: Upgrade path from old package not provided

[Scott Kitterman]

Package: olive-editor
Version: 20181223-1
Severity: serious
Justification: Policy 7.6

Because olive-editor doesn't provide a olive binary transitional package
(which would depend on olive-editor), the proper upgrade path is not provided.

Please add a transitional package so that users will end up with the correct
package installed.

Scott K

Bug#915524: Acknowledgement (RFS: filemanager-actions/3.4-1 [ITP])

[Jeremy Bicha]

 Hi,

I apologize for the late review. Reviewing your package has been on my
todo list for several weeks. I think it will be appropriate for us to
ask for an exception to ensure it gets into the Buster release even
though it will be a bit late from the freeze deadline.

I imported your git repo to
https://salsa.debian.org/debian/filemanager-actions and gave you
access to it. I also pushed a small update to your debian/gbp.conf
there.

I don't need you to upload changes to mentors, I prefer sponsoring
from the git repo instead of from a .dsc.

1. Could you rename the extension packages to nautilus-extension-fma, etc. ?

2. Why do you have gtk-doc stuff in your -dev package instead of in
your -doc package?

3. Could you just not install the .la files?

4. I think your debian/source/options is unnecessary.

5. I don't think your backup.tar stuff is necessary at all. I
recommend removing all of it.

Other Comments: No Action Needed Before Upload
--
6. If you don't like autotools clutter, I suggest you work with
upstream to switch the package to meson later.

7. Please ask upstream to provide an app icon that is at least 64px so
we can drop all the svg conversion handling and that autopkgtest.

8. You might want to work with upstream to remove the scrollkeeper/omf
stuff. scrollkeeper was removed from Debian recently and isn't
necessary or used any more. That should allow you to drop nocheck.

Thanks,
Jeremy Bicha

Bug#921711: libusrsctp1: typo in homepage

[Jonas Smedegaard]

Quoting Michael Becker (2019-02-08 14:35:09)
> that completely addresses my concerns.

Good.

Thanks for pointing this out, and for being cautious if getting properly 
addressed - much appreciated!


 - Jonas

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

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


signature.asc
Description: signature

Bug#921717: RFA: cyrus-imapd -- Cyrus mail system - IMAP support

[Ondřej Surý]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I request an adopter for the cyrus-imapd package due to the lack of
time on my and hmh's side.

The package description is:
 Cyrus is an IMAP server designed to handle massive quantities of mail,
 with a number of features not found in other IMAP implementations,
 including support for:
  - running the daemon without root privileges;
  - POP3 and NNTP in addition to plain IMAP;
  - CalDAV and CardDAV;
  - secure IMAP using SSL;
  - server-side filtering with Sieve;
  - mail users without login accounts;
  - simple mail quotas;
  - virtual domains;
  - IPv6.
 .
 This package contains the IMAP (Internet Mail Access Protocol) portion
 of the Cyrus IMAPd suite.
 .
 For more information, please see the cyrus-common package.
 Cyrus is an IMAP server designed to handle massive quantities of mail,
 with a number of features not found in other IMAP implementations,
 including support for:
  - running the daemon without root privileges;
  - POP3 and NNTP in addition to plain IMAP;
  - CalDAV and CardDAV;
  - secure IMAP using SSL;
  - server-side filtering with Sieve;
  - mail users without login accounts;
  - simple mail quotas;
  - virtual domains;
  - IPv6.
 .
 This package contains the IMAP (Internet Mail Access Protocol) portion
 of the Cyrus IMAPd suite.
 .
 For more information, please see the cyrus-common package.

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlxdYQVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcI6bg/+Pv5UMLxFMwA3ZKBxmBmTvhv44smSqc/r6dKlbfsJjoLX90BWJNf1Kv48
772nTNSyMwsrgEaSvrTJs2Oh9Wq2o1HsfotM2FJuVF+BcOTd5j/raAg9ljRfPz7n
UujF6aW04dmR/rnG1yvqGWrdFNtqdaGgLfCpqdwnal/E4xsxHNkcjFNqptAekj6Z
30uARZPK+ceWzvFvo8ZeMudrrsD706SyDHT5Ry2+zE440P8e/UReUoTU77+iCoth
gKzPEeLwiXMFiQyiTceYJBmBhJYDU/VthknmK5kHynHAIwJ39jDm3+kPirtSlSUu
IFxp3fxcssk6TKouOyOErlQNUr7tP75uw5bdU8y40PI5GeMW9iZGTcx7RZZ69oQB
OD65Q+9ULMWmSby4uWqsoA3uRkF4q1aNhzFxbK7gFcVyGDYPc/DBPvtj9khabVzp
y50Ra2vtwFTQbBR1PCS3PJ6mFHLUwe6KC6/PRXH3FdrYv/RBp3aDS3Ys+aM5tYIG
iWUUYOkOLtTE5LFutnDg1TO+i2oJUGRftZtZqF57w/PDHR69roGww5m+athjyxM0
ThIAJetB4TjL6TzvEaNrbDTZV2IYH3cB2AnCgo4MazELwPc+SEQNRvaV8hSy/xEn
lsrgijGbSk8NhPInicFVueQzU8fjxtrrf3aXqx4pHT/rWjqNpCY=
=4qfj
-END PGP SIGNATURE-

Bug#921718: spring is broken /usr/lib/ruby/vendor_ruby/spring/client/run.rb:76:in `spawn': No such file or directory - /usr/lib/ruby/bin/spring (Errno::ENOENT)

[Pirate Praveen]

Package: ruby-spring
version: 2.0.2-1
severity: serious
justification: breaks rails newapp autopkgtest

Bundle complete! 18 Gemfile dependencies, 76 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
run  bundle exec spring binstub --all
* bin/rake: spring inserted
* bin/rails: spring inserted
+ cd foo
+ rails runner puts "Empty Rails %s app booted correctly" % 
Rails.version
Warning: Running `gem pristine --all` to regenerate your installed 
gemspecs (and deleting then reinstalling your bundle if you use bundle 
--path) will improve the startup performance of Spring.
/usr/lib/ruby/vendor_ruby/spring/client/run.rb:76:in `spawn': No such 
file or directory - /usr/lib/ruby/bin/spring (Errno::ENOENT)

from /usr/lib/ruby/vendor_ruby/spring/client/run.rb:76:in `boot_server'
from /usr/lib/ruby/vendor_ruby/spring/client/run.rb:56:in `cold_run'
	from /usr/lib/ruby/vendor_ruby/spring/client/run.rb:33:in `rescue in 
call'

from /usr/lib/ruby/vendor_ruby/spring/client/run.rb:30:in `call'
from /usr/lib/ruby/vendor_ruby/spring/client/command.rb:7:in `call'
from /usr/lib/ruby/vendor_ruby/spring/client/rails.rb:24:in `call'
from /usr/lib/ruby/vendor_ruby/spring/client/command.rb:7:in `call'
from /usr/lib/ruby/vendor_ruby/spring/client.rb:30:in `run'
from /usr/bin/spring:49:in `'
from /usr/lib/ruby/vendor_ruby/spring/binstub.rb:31:in `load'
	from /usr/lib/ruby/vendor_ruby/spring/binstub.rb:31:in `(required)>'
	from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
	from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
	from 
/tmp/autopkgtest-lxc.y861r_eq/downtmp/autopkgtest_tmp/foo/bin/spring:15:in 
`'

from bin/rails:3:in `load'
from bin/rails:3:in `'
autopkgtest [16:28:40]: test newapp: ---]
autopkgtest [16:28:40]: test newapp:  - - - - - - - - - - results - - - 
- - - - - - -

newapp   FAIL non-zero exit status 1

Bug#921236: [Pkg-zsh-devel] Bug#921236: Bug#921236: zsh: provide equivalent of dh_bash-completion

[Frank Terbeck]

Daniel Shahaf wrote:
> [...] and autoloadable
> functions (first line is "#autoload") to /usr/share/zsh/vendor-functions;
> both of these paths are Debian-specific.  I suggest that, at least for
> now, you manually install the files to these paths.

vendor-functions takes any sort of zsh function file, "#autoload" or
manually loaded.

Bug#921700: [xpra] FTBFS: xvfb path patch

[Antonio Russo]

On 2/8/19 2:47 AM, Dmitry Smirnov wrote:
> On Friday, 8 February 2019 4:57:35 PM AEDT Antonio Russo wrote:
>> At least on my setup,  detect_xorg_setup(install_dir)  in setup.py already
>> produces
>>
>> xvfb_command[0] == '/usr/lib/xorg/Xorg'
>>
>> (around line 822 in setup.py).
>>
>> The assertion installed by our Debian specific patch does not consider
>> that as a possibility. The attached updated patch relaxes the assertion,
>> resolving the FTBFS.
> 
> First of all let's not inflate the severity please.
> 
> I could not reproduce FTBFS is pristine build environment (as the package is 
> built) so why do we need this patch?? I do not understand...
> 
> Upstream builds Xpra in/for many environments be we do not as we only need to 
> build it for "unstable".
> 

I don't see any particular value in arguing about whether a failure to build 
from
source constitutes a "severe" violation of Debian policy if we can just instead
resolve the issue.

Do you have a technical objection to the patch I submitted (which also improves
the reproducibility of the build, another stated goal of Debian policy)? It's a
very low-risk patch.

If not, I can roll the patch into a MR on salsa.

Bug#921721: broken "Homepage" link

[Robert Bihlmeyer]

Package: open-infrastructure-apache-tools
Version: 20170701-3
Severity: minor

The package links to
  https://open-infrastructure.net/software/service-tools
which 404s. I think it wants to linke to
  https://open-infrastructure.net/software/apache-icons/
instead.

Bug#906016: transition: gjs built with mozjs60

[Emilio Pozuelo Monfort]

Hi,

On 05/02/2019 11:16, Simon McVittie wrote:
> Please could we have a decision on this in plenty of time before the freeze?
> Given the upstream GC improvements aimed at mitigating or solving "the memory
> leak problem" in gjs 1.54.x, I am not comfortable with releasing buster with
> gjs 1.52.x (which has a backport of those changes done by a developer who does
> not have in-depth knowledge of gjs, namely me); so I would like to ask for a
> freeze exception to complete this transition.

Yes, it is my intention to finish this.

> On Thu, 17 Jan 2019 at 10:25:01 +0100, Emilio Pozuelo Monfort wrote:
>> On 17/12/2018 15:56, Simon McVittie wrote:
>>> The options I can see are:
>>>
>>> * Accept that task-gnome-desktop is not going to be installable on s390x.
>>>   Change the testing migration scripts to skip installability testing for
>>>   that package on s390x, or ignore the fact that it fails. Optionally
>>>   change tasksel to make task-gnome-desktop Architecture: any, and give it
>>>   some Build-Depends-Arch that are not satisfiable on s390x so that it will
>>>   not be built there.
>>>   - s390x d-i users will not be able to install a GNOME desktop. Hopefully
>>> the menu item would not appear, and task-desktop would pick up the
>>> second-preference desktop instead, which currently seems to be XFCE?
>>>   - Risk: is it possible to ignore uninstallability of task-gnome-desktop
>>> without ignoring uninstallability of other task packages?
> 
> I would prefer this option if possible: the GNOME desktop is clearly not
> intended for use on mainframes, and I doubt anyone is seriously trying to use
> it there (as opposed to individual GNOME apps in a remote-desktop framework,
> which might be something that people do). However, it requires action from the
> release team and d-i maintainers.

Cyril, can we do something to not offer task-gnome-desktop on s390x? Does that
need changes in d-i or tasksel?

>>> * Require task-gnome-desktop to be installable on s390x, but modify
>>>   meta-gnome3 so that on s390x, gnome-core installs something that is not
>>>   the full GNOME 3 desktop used on other architectures, for example
>>>   the GNOME-2-derived gnome-session-flashback instead of gnome-session and
>>>   gnome-shell, and lightdm instead of gdm3.
>>>   - s390x users will not get the same GNOME desktop everyone else does.
>>>   - Risk: if GNOME Flashback becomes unsupportable in some future release
>>> (it's a GNOME 2 derivative a bit like MATE, although without using
>>> forks of the apps, and most upstream and downstream GNOME maintainers
>>> don't use or maintain it), we're back where we started.
> 
> With the freeze approaching fast, if we can't have a solution that requires
> action to be taken outside the GNOME team, this is probably the best thing 
> that
> the GNOME team can do unilaterally. An untested git branch for this:
> https://salsa.debian.org/gnome-team/meta-gnome3/merge_requests/3

Alternatively, this is probably the way to go.

Cheers,
Emilio

Bug#914591: stretch-pu: package python-cryptography/1.7.1-3

[Sebastian Andrzej Siewior]

On 2019-02-08 12:55:28 [+], Adam D. Barratt wrote:
> Hi,
Hi,

> Apologies for the delay in getting back to you on this.
no worries.

> On 2018-11-25 12:49, Sebastian Andrzej Siewior wrote:
> > Any feedback from the python team is welcome.
> 
> Was there any feedback?

nope, nothing at all.

> Regards,
> 
> Adam

Sebastian

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

On 2019-02-08 14:02:14 +0100, Egmont Koblinger wrote:
> > Yes, but my point is that the default should not be broken.
> 
> One could argue that the wheels working in "less" (or any other
> similar app) is the expected behavior, and not working at all is the
> broken one...

No, that's just a feature. And what gnome-terminal does is buggy
in "less", and completely broken in Mutt and in GNU Screen + bash
(this can even freeze Screen, which doesn't seem to be able to
handle so many events at once!). What gnome-terminal assumes is
that  and  does scrolling. This may be the case with
some applications (possibly under some context only), but these
keys may also do something completely different. Thus this is a
wrong assumption.

Perhaps it should have generated scroll-backward (kR) and
scroll-forward (kF) keys, and provided a terminfo that defines
them. That way, this wouldn't mix up with the  and 
keys.

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

Bug#921639: [pkg-netfilter-team] Bug#921639: iptables-restore: cannot jump to earlier initialized chain

[Miquel van Smoorenburg]

On 07/02/2019 17:36, Arturo Borrero Gonzalez wrote:
> On 2/7/19 4:16 PM, Miquel van Smoorenburg wrote:
>> *filter
>> :FILERS_UDP - [0:0]
>> :FORWARD ACCEPT [0:0]
>> :INPUT ACCEPT [0:0]
>> :OUTPUT ACCEPT [0:0]
>> -A FILERS_UDP --protocol udp --dport sunrpc --source 10.0.79.0/27 --jump
>> ACCEPT
>> -A INPUT --protocol udp --source 10.0.0.0/8 --jump FILERS_UDP
>> COMMIT
> 
> Please, share your linux kernel version. May be a Linux kernel issue already 
> solved.

This was indeed on an ancient kernel (4.9). I just installed the latest
buster using the buster alpha 5 installer in a VM, and re-tested.
Indeed, the problem is gone.

I'm sorry for bothering you. Thanks!

Mike.

Bug#921687: [debian-mysql] Bug#921687: systemctl just hangs on stoping or starting mysql-server-5.7

[Robie Basak]

Hi,

Could this be the issue described here:
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1600164 ?

Apart from that, I don't know of anyone else affected by this, so I
don't think we can treat it as a bug in the mysql-server-5.7 package
without further details of why it must be a bug or having steps to
reproduce the issue.

Robie


signature.asc
Description: PGP signature

Bug#821115: RFP: csdr -- DSP library and command-line tool for Software Defined Radio

[Christoph Berg]

Re: Iain R. Learmonth 2017-10-21 

> retitle 821115 RFP: csdr -- DSP library and command-line tool for Software 
> Defined Radio
> noowner 821115
> kthxbye
> 
> Hi,
> 
> I'm never going to have time to chase up emscripten to get this done.
> 
> Someone else should have a go if they have the time.

Fwiw, I'm archiving the csdr git on salsa. If this is picked up again,
it's easy enough to un-archive it.

https://salsa.debian.org/debian-hamradio-team/csdr

Christoph

Bug#919641: transition: readline (7 -> 8)

[Emilio Pozuelo Monfort]

On 18/01/2019 08:45, Matthias Klose wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> readline is in experimental for some time, the changes are API compatible, and
> afaics there are no build failures caused by readline. I filed some RC issues
> for unrelated ftbfs.
> 
> A handful of packages need sourceful uploads, like d-shlibs and 
> readline-perl6.

As discussed over irc, let's postpone this for bullseye.

Cheers,
Emilio

Bug#921723: icingaweb2: upgrading package break the database connection

[Max]

Package: icingaweb2
Version: 2.6.2-2
Severity: important

Dear Maintainer,

after upgrade the login page show this error:

Fatal error: Uncaught error: Undefined class constant
'MYSQL_ATTR_INIT_COMMAND' in /usr/share/php/Icinga/Data/Db/DbConnection.php:196
stack trace: bla bla bla ...

the package php7.2-mysql is marked as unused and removed automatically from the 
system.
I suppose is needed

thanks for support


-- 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages icingaweb2 depends on:
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra2.37-1
ii  icingaweb2-common 2.6.2-2
ii  php-xml   2:7.3+69
ii  php7.2-xml [php-xml]  7.2.9-1
ii  php7.3-xml [php-xml]  7.3.1-3

Versions of packages icingaweb2 recommends:
ii  apache2 [httpd]   2.4.38-2
ii  icingacli 2.6.2-2
ii  icingaweb2-module-doc 2.6.2-2
ii  icingaweb2-module-monitoring  2.6.2-2
ii  php   2:7.3+69
ii  php-curl  2:7.3+69
ii  php-gd2:7.3+69
ii  php-imagick   3.4.3-4
ii  php-intl  2:7.3+69
ii  php-ldap  2:7.3+69
ii  php7.2 [php]  7.2.9-1
ii  php7.2-cli [php-cli]  7.2.9-1
ii  php7.2-gd [php-gd]7.2.9-1
ii  php7.2-json [php-json]7.2.9-1
ii  php7.3 [php]  7.3.1-3
ii  php7.3-cli [php-cli]  7.3.1-3
ii  php7.3-curl [php-curl]7.3.1-3
ii  php7.3-gd [php-gd]7.3.1-3
ii  php7.3-intl [php-intl]7.3.1-3
ii  php7.3-json [php-json]7.3.1-3
ii  php7.3-ldap [php-ldap]7.3.1-3

icingaweb2 suggests no packages.

-- no debconf information

Bug#921642: stretch-pu: package libemail-address-perl/1.908-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2019-02-07 15:27, Dominic Hargreaves wrote:
Fixes CVE-2015-7686 and CVE-2018-1255 which are exposed by 
request-tracker4.

Candidate package deployed and working so far on a production system.


Please go ahead, bearing in mind that the window for 9.8 closes this 
weekend.


Regards,

Adam

Bug#906258: stretch-pu: package yubico-piv-tool/1.4.2-2

[Adam D. Barratt]

On 2018-09-08 01:00, Nicolas Braud-Santoni wrote:

Control: tag -1 - moreinfo

Hi Adam,

Sorry for getting back to you this late.


Likewise apologies for overlooking the response for so long.


On Wed, Aug 29, 2018 at 08:21:18AM +0100, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

Why does the diff contain (and not mention):

 upstream-signing-key.pgp
1451 ---
 upstream-signing-key.pgp.backup
1451 +++
 upstream/signing-key.asc
1966 ++

?


It seems the tags in the packaging repo do not actually match the 
uploads
to the archive, and I do not know why: this is a team-maintained 
package,
and the Yubico folks who did the original packaging (and are part of 
the
team) seem to have lost interest in maintaining their packages, so I 
have

no idea which process they were using.


Sure, but when you upload the package it needs to contain the changes 
you expect. So either the change should be reverted, or it should be 
documented in the changelog (ideally with rationale).



It looks like something was uploaded, though:


Didn't you do that? (Or your sponsor, I guess, but I still assumed you'd 
be aware.)



$ rmadison -s stable,stable-new yubico-piv-tool
yubico-piv-tool | 1.4.2-2| stable | source, amd64, arm64, 
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

yubico-piv-tool | 1.4.2-2+deb9u1 | stable-new | source, amd64


I assume you removed the bogus upstream-signing-key.pgp change?


I didn't remove anything, no. I have nothing to do with the package, 
just looking at what's been proposed / uploaded in order to decide 
whether to accept it.


Regards,

Adam

Bug#914591: stretch-pu: package python-cryptography/1.7.1-3

[Adam D. Barratt]

Hi,

Apologies for the delay in getting back to you on this.

On 2018-11-25 12:49, Sebastian Andrzej Siewior wrote:

With the intention of pushing OpenSSL 1.1.0j into Stretch here is the
proposed change for python-cryptography.
The package python-cryptography fails to build due to an API change of
BIO_callback_ctrl() in OpenSSL. While this is a no-no in a stable
release, it has been explained [0] that the function / callback was
always used with a different prototype. I fixed this by removing the
function / prototype from the python wrapper while upstream removed the
almost all BIO related wrappers [1].
I did a rebuild of python-cryptography's rdeps in Stretch against 
OpenSSL

1.1.0i and the proposed package with no fallout [2].

Any feedback from the python team is welcome.


Was there any feedback?

Regards,

Adam

Bug#918437: ring-clojure: FTBFS randomly due to filesystem ordering

[Cyril Brulebois]

Hi,

Santiago Vila  (2019-01-06):
> This happens because the "find path | xargs clojure" construction
> which was common in many clojure packages is prone to error as its
> success or not depends critically on the output order of the find
> command.
> 
> Cyril Brulebois has already fixed several similar packages so I'm
> just Cc:ing him.

I don't seem to have received a copy but I was chased down on IRC
anyway. Pushed a commit to fix this but I'm now hitting issues with
jh_classpath that I'm not sure how to fix:
|jh_classpath
| error: Can't rename /usr/share/java/ring-core-1.6.2.jar as 
/usr/share/java/ring-core-1.6.2.zbk Permission denied 
|  at /usr/share/perl5/Archive/Zip/Archive.pm line 471.
|   
Archive::Zip::Archive::overwriteAs(Archive::Zip::Archive=HASH(0x563056bf7140), 
"/usr/share/java/ring-core-1.6.2.jar") called at 
/usr/share/perl5/Archive/Zip/Archive.pm line 439
|   
Archive::Zip::Archive::overwrite(Archive::Zip::Archive=HASH(0x563056bf7140)) 
called at /usr/bin/jh_manifest line 342
|   main::update_jar("/usr/share/java/ring-core-1.6.2.jar", undef) called 
at /usr/bin/jh_manifest line 147
| jh_manifest: Writing modified jar (/usr/share/java/ring-core-1.6.2.jar) 
failed: Permission denied
| jh_classpath: jh_manifest -plibring-core-clojure 
"--classpath=/usr/share/java/clojure.jar /usr/share/java/tools.reader.jar 
/usr/share/java/ring-codec.jar /usr/share/java/commons-io.jar 
/usr/share/java/commons-fileupload.jar /usr/share/java/clj-time.jar 
/usr/share/java/crypto-random.jar /usr/share/java/crypto-equality.jar" 
/usr/share/java/ring-core.jar returned exit code 13
| make: *** [debian/rules:10: binary] Error 13

Trying to remove the leading slash in debian/*.classpath makes this
issue (EPERM) go away but I'm seeing this now which doesn't seem very
reassuring:
| jh_classpath: Cannot find usr/share/java/ring-servlet.jar: skipping
| jh_classpath: Cannot find /usr/share/java/ring-jetty-adapter.jar: skipping

so I'll leave that to someone else to fix. :/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#921724: FTBFS - gcc-m68hc1x doesn't compile on ppc64el

[Thierry fa...@linux.ibm.com]

Package: gcc-m68hc1x
Version: 1:3.3.6+3.1+dfsg-3+b2

Severity: normal

With version 1:3.3.6+3.1+dfsg-3+b2

(sid
) ,
package is not compiled any more

With version 1:3.3.6+3.1+dfsg-3 it failed with



** Configuration powerpc64le-unknown-linux-gnu not supported
Configure in /«BUILDDIR»/gcc-m68hc1x-3.3.6+3.1+dfsg/build/gcc failed, 
exiting.
debian/rules:28: recipe for target 'configure-stamp' failed

Bug#917456: "not everyone..."

[PICCORO McKAY Lenz]

> Not everyone is in need for NAT tricks.

the problem its not about who need NAT or use it!

THE PROBLEM its that the package actually dont works! and was made in main
for that!

and releases are normal github releases so i dont see the difficult

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#921731: ITP: icingaweb2-module-reactbundle -- 3rd party libraries useful for Icinga Web 2 modules

[Kunz David]

Package: wnpp
Owner: david.k...@dknet.ch

* Package name: icingaweb2-module-reactbundle
  Upstream Author : Icinga Development Team 
* License : 
  Description : 3rd party libraries useful for Icinga Web 2 modules

  Icinga Web 2 is a very modular, fast and simple web interface for 
  your Icinga monitoring environment.
  .
  This module is an attempt to ship 3rd party libraries that might be
  useful for asynchronous PHP-based Icinga Web 2 modules.

Greetings,
David

Bug#921646: kdepim-runtime: akonadi_imap_resource fails to download gmail content

[Sandro Knauß]

Hey,

thanks for your input. So far your bugreport sounds like gmail banning the 
account temporarily for exceeding some limit. They do such things. So just 
retry some hours later, than you should download more. Hopefully that helps. 
Unfortunately we do not have a way to display those bans to users.

hefee


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

Bug#921164: kubectx: FTBFS in sid

[Santiago Vila]

> Could you help to provide the exact command that cause FTBFS?  I use the
> following command to build with pbuilder, and it can be built
> successful.
> 
> $ gbp buildpackage --git-pbuilder

I'm using sbuild + schroot, as used in the official buildds, so the
command would be something like this:

sbuild --arch-all --no-arch-any -d sid kubectx

assuming you have a chroot called "sid".

I can also make it fail in this way:

unset TERM; dpkg-buildpackage -uc -us -A

Are you relying on TERM being defined? Maybe that's the root of the problem.
Packages must be buildable with sbuild, not just gbp or dpkg-buildpackage.

Thanks.

Bug#921734: xwayland: crash when running kde plasma

[Jonathan]

Package: xwayland
Version: 2:1.20.3-1
Severity: important

Dear Maintainer,

Running Plasma wayland quickly crashes after a few mouse clicks. A typical
desktop user can only poweroff since screen frozen and mouse/keyboard no longer
work.

Tracked xwayland crash part by running;
startplasmacompositor > plasma-error.txt 2>&1

Appears (not tested by me) to be patched upstream in report
https://bugs.freedesktop.org/show_bug.cgi?id=106930



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages xwayland depends on:
ii  libaudit1   1:2.8.4-2
ii  libbsd0 0.9.1-1
ii  libc6   2.28-6
ii  libdrm2 2.4.97-1
ii  libegl1 1.1.0-1
ii  libepoxy0   1.5.3-0.1
ii  libgbm1 18.3.2-1
ii  libgcrypt20 1.8.4-5
ii  libgl1  1.1.0-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.8-1+b1
ii  libsystemd0 240-5
ii  libunwind8  1.2.1-8
ii  libwayland-client0  1.16.0-1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.3-1

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#921739: amtool: error: comment required by config

[Santiago Vila]

Package: prometheus-alertmanager
Version: 0.15.3+ds-2

Hello again.

File /usr/share/doc/prometheus-alertmanager/README.md.gz suggests doing this:

amtool silence add alertname=Test_Alert

but this is what I get:

amtool: error: comment required by config

Trying to see what's wrong, I tried using amtool 0.16.1, downloaded
from github:

$ /tmp/amtool silence add alertname=Test_Alert
amtool: error: required flag --alertmanager.url not provided

Ok, apparently it needs the url of the current alertmanager instance,
let's try this then:

$ /tmp/amtool --alertmanager.url=http//:localhost:9093 silence add 
alertname=Test_Alert

Output:

amtool: error: comment required by config

So, back to square one. Is there a trick to make this work? Maybe I'm
missing something, but I don't know what it could be.

I would love to use the web UI, but it's gone:

 The Debian package of the alertmanager does not include a web
 application.

Is this a Debian-specific change? If yes, could we have the web UI back?
In my opinion, it was better than nothing.

Thanks.

Bug#921268: [mumble] Mumble's Audio Tuning Wizard doesn't play test samples/sounds, TTS is possibly also broken

[Chris Knadle]

Hello Mikaela.

Mikaela Suomalainen:
> Package: mumble
> Version: 1.3.0~git20190125.440b173+dfsg-1
> Severity: normal
> 
> --- Please enter the report below this line. ---
> 
> Hi,
> 
> I think this issue was introduced by 1.3.0~git20190114.9fcc588+dfsg-1.
> When I open the audio wizard, the third screen is device tuning which
> says "You should hear a voice sample. Change the slider below to the
> lowest value which gives no interruptions or jitter in the sound", and
> here I don't hear sound at all.

I've tested this and I see the same behavior.

> Later there is "Positional Audio" configuration, where the last phrase
> is "You should hear the audio move between the channels". There is no
> audio here either. I experience this issue on both headset and laptop
> internal speaker/microphone, and also HDMI audio.

I've tested and see the same behavior with this too.

> I am not entirely sure when I should hear TTS, but I think it's also
> broken as I don't hear messages while connecting and disconnecting to
> server, which I think I heard previously.

Text-To-Speech still works in my testing, but didn't at first and I found why.
Check to be sure you have the 'speech-dispatcher' package installed.  If not,
install it.  The Mumble client does not need re-loading to get TTS to work if
speech-dispatcher wasn't installed before.

speech-dispatcher isn't a dependency for Mumble and I think that's purposeful;
there have been some bugs and occasional misbehavior related to
speech-dispatcher such that I find it beneficial not to have it installed when
it's not required.


I'm not sure what's going on with the missing audio samples, but I've seen
discussion about that in the #mumble IRC channel on irc.freenode.net, so there's
a possibility that this might be by design.  I'll ask upstream.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



signature.asc
Description: OpenPGP digital signature

Bug#921695: closed by Guido Günther (Bug#921695: fixed in libvirt-glib 2.0.0-1)

[Jeremy Bicha]

Oh, it doesn't involve a transition?

That looks like strange version numbering from upstream then.

Jeremy

Bug#820911: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

[Holger Wansing]

Hi,

Samuel Thibault  wrote:
> Hello,
> 
> Holger Wansing, le mar. 01 janv. 2019 23:40:29 +0100, a ecrit:
> > I have played with the syslinux config for legacy BIOS mode, and as far as I
> > can test, it works for the netboot-gtk image, see the patch attached plus 
> > some 
> > new files that need to be added (for debian-installer/build/boot/x86).
> 
> I have reworked it and applied it.

That's great, thanks!

Regarding the documentation in the installation-guide:
maybe we could add something about how to use the dark theme via keyboard 
shortcuts?
(if that's not too complex, because of differences between grub and syslinux, 
etc.)

Something like 
"There are also keyboard shortcuts available, to activate this: 
type 'd' + 'i' at the boot prompt for the text-based install or
'd' + 'g' for graphical installation.

Will need to investigate the exact shortcuts though...



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#921164: kubectx: FTBFS in sid

[陳昌倬]

On Sat, Feb 02, 2019 at 02:27:23PM +, Santiago Vila wrote:
> Package: src:kubectx
> Version: 0.6.3-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in sid but it failed:

Hi Santiago,

Could you help to provide the exact command that cause FTBFS?  I use the
following command to build with pbuilder, and it can be built
successful.

$ gbp buildpackage --git-pbuilder

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#920329: marked as done (libnode64: Please include libv8_*.so libraries)

[Jérémy Lal]

Le ven. 8 févr. 2019 à 15:57, Debian Bug Tracking System <
ow...@bugs.debian.org> a écrit :

> Your message dated Fri, 08 Feb 2019 14:55:40 +
> with message-id 
> and subject line Bug#920329: fixed in nodejs 10.15.1~dfsg-3
> has caused the Debian Bug report #920329,
> regarding libnode64: Please include libv8_*.so libraries
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 920329: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920329
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Philipp Marek 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Thu, 24 Jan 2019 09:17:24 +0100
> Subject: libnode64: Please include libv8_*.so libraries
>
> Package: libnode64
> Version: 10.15.0~dfsg-9
> Severity: minor
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785696 talks about
> using
> libnode{64,-dev} to get a newer v8 library, and that works fine.
>
> Please include the libv8_* libraries as well;
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1517657
> talks about Fedora including them, and
>
>
>
> http://forums.armory3d.org/t/linux-build-complains-about-libv8-libbase-so-not-existing/1083/3
> is another Debian user requesting them.
>
>
> The list of binaries that I seem to miss is
>  v8_libbase
>  v8_libplatform
>  v8_base
>  v8_external_snapshot
>  v8_libsampler
>  v8_data
>
> but if there are any other ones as well, please just pass them on, too!
>
>
> Thank you very much.
>

Hi,

i'm uploading a new revision to experimental (-4) right now with these
links:
libv8_libbase.so
libv8_libplatform.so
libv8_libsampler.so

i think that's all that is needed.
Jérémy

Bug#921643: stretch-pu: package libemail-address-list-perl/0.05-1+deb9u1

[Dominic Hargreaves]

On Fri, Feb 08, 2019 at 12:47:28PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2019-02-07 15:28, Dominic Hargreaves wrote:
> > Fixes CVE-2018-18898 which is exposed by request-tracker4.
> > Candidate package deployed and working so far on a production system.
> 
> Please go ahead, bearing in mind that the window for 9.8 closes this
> weekend.

Uploaded.

Bug#921631: [Pkg-salt-team] Bug#921631: salt-master: gitfs requires git when using pygit2 as gitfs_provider

[Benjamin Drung]

Am Donnerstag, den 07.02.2019, 08:21 -0500 schrieb Malcolm Acker:
> When using pygit2 as the gitfs_provider critical errors are thrown in
> the error log if the git package is not installed:
>   2019-02-07 07:44:20,180 [salt.utils.gitfs :2565][ERROR   ][2577]
> The git command line utility is required when using the 'pygit2'
> gitfs_provider.
>   2019-02-07 07:44:20,181 [salt.utils.gitfs :2468][CRITICAL][2577] No
> suitable gitfs provider module is installed.
>   2019-02-07 07:44:20,185 [salt.loader  :1702][ERROR   ][2577]
> Failed to load function git.envs because its module (git) is not in
> the whitelist: ['gitfs', 'roots']
> 
> Installing the Debian git package and restarting salt-master resolves
> this issue.  I have briefly tested the pygit2 python module (https
> clone, commit log listing) and it does not appear the python module
> on it's own requires the git binary.

I checked salt/utils/gitfs.py and found out that
GitProvider.clean_stale_refs() calls 'git remote prune origin'. This
function is used by Pygit2._fetch(). So the git binary is still needed,
unless you want to replace the 'git remote prune origin' call with a
native pygit2 call.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#921738: chromium-widevine: Widevine does not work with Netflix

[Pedro Ribeiro]

Package: chromium-widevine
Version: 71.0.3578.80-1~deb9u1
Severity: grave
Justification: renders package unusable

Netflix keeps saying:
Your web browser is missing a digital rights component. Go to
chrome://components and under WidevineCdm, click Check for update.

I have installed the chromium-widevine package, together with the correct
version of chromium, and still complains about the missing plugin.

To solve it, I need to download a binary blob from Google:
wget https://dl.google.com/widevine-cdm/1.4.8.1008-linux-x64.zip
unzip 1.4.8.1008-linux-x64.zip
sudo mkdir /usr/lib/chromium
sudo mv libwidevinecdm.so /usr/lib/chromium
sudo chmod 644 /usr/lib/chromium/libwidevinecdm.so

Looks like I'm not the only one having this problem:
https://unix.stackexchange.com/questions/385880/using-the-chromium-widevine-
debian-package

Thanks!



-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (750, 'stable'), (650, 'testing'), (600, 'unstable'), (550, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.20-grsec-botto+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages chromium-widevine depends on:
ii  chromium  71.0.3578.80-1~deb9u1

chromium-widevine recommends no packages.

chromium-widevine suggests no packages.

-- no debconf information

Bug#921723: [Pkg-nagios-devel] Bug#921723: icingaweb2: upgrading package break the database connection

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

On 2/8/19 1:25 PM, Max wrote:
> after upgrade the login page show this error:
> 
> Fatal error: Uncaught error: Undefined class constant
> 'MYSQL_ATTR_INIT_COMMAND' in 
> /usr/share/php/Icinga/Data/Db/DbConnection.php:196
> stack trace: bla bla bla ...
> 
> the package php7.2-mysql is marked as unused and removed automatically from 
> the system.
> I suppose is needed

No, php7.3 is now the default, make sure that you're using that instead
instead of 7.2.

If the issue persist, it may be that mariadb-10.3 doesn't provide
MYSQL_ATTR_INIT_COMMAND any more.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#921733: prevent migration while I am out of town

[Ondřej Surý]

Package: src:cyrus-imapd
Version: 3.0.8-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is new upstream major release and it needs to be tested by people
with real cyrus-imapd installations, so I am just preventing the
migration to testing while I without Internet access next week.

To release team - just ignore this.

Ondrej

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

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

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlxdoSZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKsrQ/6Ai5PnyEEPtZBK4odg1OZpW7SII/s2dZ00oqEaa9YCC4fJUqpmSufR+Du
RO4R4+T5spg49U/zSm6NrHhdRMVsZ7XTN8smQC+/TSsfutJI8Y40tRHMyMieCx0i
9lt6qcarD16nWyfhdVEs6WQBecBJWcqCD16vTjI5BefAb56YkfaI6650hlh/GQyX
eByq+ugbqb9Kxpsu6PDQLbE9GH+DHO58jHh+1CK1wPVXxXpB7+tDI08+OwAZkgA9
42pV7fu08eBR6HuOC6scWEzBORUZ5stVah8P/a45r6D8UO/Bh18lfHGXu2+EXTOV
cgQ8l4qboPR+lxVS+65NOw1jXcLpUorpOYTXJyhQ//yzDQsHlrtoo9kfxAn4CKAG
NhUdiySEckI2P2M8i+NcNKH344JCKEoymT4wAfogSML9A6mDflI8rJAf34WtOYlx
21MoTfhxjtOCvXg0W5QV+x1qFX6JAuw/B6UWFwASZFdY9mpxM+9ePHsRIw9YfjFz
NvdHubC/kWRtKo/CuA7uyXr71VNQ/l2ro7pdH53lhFwR1nngLWPH6QKKa8KssGFZ
Fi0QHIzUF0hcQEJsmpeC6+07nhQ+g18n8E07eflJJ6Qo4IhWN7k/PfFtdWE9Qz1F
uOCqrjhiiN1xkSrw/ugpnXh7wrMfkbxHJs+EDItvNbYZqlv7gH0=
=/Erk
-END PGP SIGNATURE-

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

[Fabian Klötzl]

Hi Andreas,

On 07.02.19 14:58, Andreas Tille wrote:

There are also build issues of libmurmurhash on some architectures[2]

Any idea what to do next?

[2] https://buildd.debian.org/status/package.php?p=libmurmurhash=sid


I hope to have fixed the build issues upstream. Have pushed a new—and 
hopefully working—version to salsa. Could you sponsor another upload? I 
will take a further look at the package next week.


Have a nice weekend
Fabian

Bug#921617: mumble: Mumble memory use increases over time to unreasonable amounts

[Chris Knadle]

Colomban Wendling:
> Le 07/02/2019 à 16:56, Chris Knadle a écrit :
>> […]
>>
>> Just to mention: this isn't the first report of "memory leak" on Mumble -- 
>> see
>> Debian bug #683827.
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683827
>>
>> I wasn't able to reproduce #683827 on newer versions of Mumble 1.2.x but 
>> wasn't
>> sure what the underlying cause/issue was there, or what version of Mumble may
>> have fixed that bug.
> 
> The links you have there are interesting; for example
> https://github.com/mumble-voip/mumble/issues/1074#issuecomment-20316
> suggests that it might be due to echo canceller and other apps "messing"
> with PulseAudio.  I do have echo canceller enabled (that I should
> actually be able to disable as I'm using push-to-talk with a headset),
> and am running at least one virtual machine which could be doing
> something with PulseAudio.
> 
> I'll try and do some tests next chance I get (probably next week).

*nod*  Okay.  Yeah the echo canceler would be part of the Mumble binary, so if
the canceler is misbehaving memory-wise then that would make sense.  However if
another virtual machine were causing issues with PulseAudio then that shouldn't
cause memory expansion/leaking in the Mumble client binary (AFAIK).

>> Due to recent security bugs in Mumble I'm going to be preparing a version of
>> Mumble 1.3 with Qt4 (targeted for Stretch) -- so there will be an 
>> opportunity to
>> test that to see if it shows the same memory leak.
> 
> I can also test if reverting to a previous version of Mumble helps; I'm
> not sure which are the security issues but in my case I trust the server
> so there might be no problem using an older version for testing.

The two recent security issues relate to mumble-server specifically, not the
client.  One security issue has been resolved, another is described in Debian
bug #919249 and on this Debian Secuirty page for CVE-2018-20743:

   https://security-tracker.debian.org/tracker/CVE-2018-20743

>> […]
>>
>> I don't personally know of a "good" way to debug memory leaks.  As far as I 
>> know
>> this involves running the target program via a debugger like GDB and figuring
>> out how to watch memory allocations and frees.  Unfortunately I don't have 
>> any
>> experience with doing that [successfully] yet.
> 
> Valgrind's memcheck is the best I know.  I'll try to see if I can run
> Mumble in it and find out what I can from there -- although it often is
> a pain starting from nothing, as many toolkits and apps have gazillions
> of innocent leaks cluttering the results.

*headsmack*  I keep forgetting about Valgrind.  I can try playing with that too,
assuming I can replicate the memory leak.

> Thanks for the input, and I'll get back here with any data I can gather
> on this.

*nod*  Thank you very much for your help.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us