Bug#909612: fakechroot: does not support renameat2

2018-12-31 Thread Johannes Schauer
Control: tag -1 + patch

Hi,

On Mon, 31 Dec 2018 16:34:51 +0100 Johannes Schauer  wrote:
> On Tue, 25 Sep 2018 23:05:45 +0200 Johannes 'josch' Schauer 
>  wrote:
> > fakechroot currently doesn't support the renameat2 system call. This means
> > that the 'mv' from coreutils in current Debian unstable and testing will not
> > work. This in turn doesn't make fakechroot very useful for using it with
> > Debian unstable and testing. Older Debian releases still work though.
> > 
> > I will leave the decision whether you consider the lack of 'mv' inside
> > fakechroot an RC bug or not up to you.
> attached patch fixes the problem.
> 
> I could NMU fakechroot with the patch. Would that be okay for you?

I uploaded a NMU to DELAYED/10. Debdiff attached. Please cancel this upload in
case you don't like it. :)

Thanks!

cheers, josch
diff -Nru fakechroot-2.19/debian/changelog fakechroot-2.19/debian/changelog
--- fakechroot-2.19/debian/changelog	2016-11-29 21:05:31.0 +0100
+++ fakechroot-2.19/debian/changelog	2019-01-01 08:05:21.0 +0100
@@ -1,3 +1,10 @@
+fakechroot (2.19-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add support for wrapping renameat2 (closes: #909612)
+
+ -- Johannes 'josch' Schauer   Tue, 01 Jan 2019 08:05:21 +0100
+
 fakechroot (2.19-3) unstable; urgency=high
 
   * Correct autoconf variables for configure. The paths should be
diff -Nru fakechroot-2.19/debian/patches/renameat2.patch fakechroot-2.19/debian/patches/renameat2.patch
--- fakechroot-2.19/debian/patches/renameat2.patch	1970-01-01 01:00:00.0 +0100
+++ fakechroot-2.19/debian/patches/renameat2.patch	2019-01-01 08:05:21.0 +0100
@@ -0,0 +1,81 @@
+From: Johannes 'josch' Schauer 
+Date: Tue, 01 Jan 2019 08:05:21 +0100
+Subject: add support for renameat2 system call
+
+--- a/config.h.in
 b/config.h.in
+@@ -526,6 +526,9 @@
+ /* Define to 1 if you have the `renameat' function. */
+ #undef HAVE_RENAMEAT
+ 
++/* Define to 1 if you have the `renameat2' function. */
++#undef HAVE_RENAMEAT2
++
+ /* Define to 1 if you have the `revoke' function. */
+ #undef HAVE_REVOKE
+ 
+--- a/configure.ac
 b/configure.ac
+@@ -252,6 +252,7 @@ AC_CHECK_FUNCS(m4_normalize([
+ removexattr
+ rename
+ renameat
++renameat2
+ revoke
+ rmdir
+ scandir
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -135,6 +135,7 @@ libfakechroot_la_SOURCES = \
+ removexattr.c \
+ rename.c \
+ renameat.c \
++renameat2.c \
+ revoke.c \
+ rmdir.c \
+ rpl_lstat.c \
+--- /dev/null
 b/src/renameat2.c
+@@ -0,0 +1,42 @@
++/*
++libfakechroot -- fake chroot environment
++Copyright (c) 2010, 2013 Piotr Roszatycki 
++
++This library is free software; you can redistribute it and/or
++modify it under the terms of the GNU Lesser General Public
++License as published by the Free Software Foundation; either
++version 2.1 of the License, or (at your option) any later version.
++
++This library is distributed in the hope that it will be useful,
++but WITHOUT ANY WARRANTY; without even the implied warranty of
++MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++Lesser General Public License for more details.
++
++You should have received a copy of the GNU Lesser General Public
++License along with this library; if not, write to the Free Software
++Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA
++*/
++
++
++#include 
++
++#ifdef HAVE_RENAMEAT2
++
++#define _ATFILE_SOURCE
++#include "libfakechroot.h"
++
++
++wrapper(renameat2, int, (int olddirfd, const char * oldpath, int newdirfd, const char * newpath, unsigned int flags))
++{
++char tmp[FAKECHROOT_PATH_MAX];
++debug("renameat2(%d, \"%s\", %d, \"%s\", %d)", olddirfd, oldpath, newdirfd, newpath, flags);
++expand_chroot_path_at(olddirfd, oldpath);
++strcpy(tmp, oldpath);
++oldpath = tmp;
++expand_chroot_path_at(newdirfd, newpath);
++return nextcall(renameat2)(olddirfd, oldpath, newdirfd, newpath, flags);
++}
++
++#else
++typedef int empty_translation_unit;
++#endif
diff -Nru fakechroot-2.19/debian/patches/series fakechroot-2.19/debian/patches/series
--- fakechroot-2.19/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ fakechroot-2.19/debian/patches/series	2019-01-01 08:05:21.0 +0100
@@ -0,0 +1 @@
+renameat2.patch


signature.asc
Description: signature


Bug#917921: rainloop: cannot launch admin panel

2018-12-31 Thread Daniel Ring

Hello Joseph,

Did you set the new admin password in the admin panel, or directly in 
the config file? The password in the config file is a salted MD5 hash 
(the default is a special case), so changing it directly won't work. MD5 
isn't particularly secure these days, but that's an issue for upstream.


If you're changing the password in the admin panel but the change 
doesn't take effect, check to make sure the PHP-FPM user has write 
permissions on /etc/rainloop/application.ini.


Sincerely,
Daniel Ring

On 12/31/2018 9:17 AM, Joseph Nahmias wrote:

Package: rainloop
Version: 1.11.1-1
Severity: important

Dear Maintainer,

I tried to follow the instructions in the README.Debian for activating
the admin panel (I changed admin_password and set allow_admin_panel =
On) but I kept getting "Authentication failed".  Only when I changed the
password back to 12345 did it work.

Help!
--Joe


-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rainloop depends on:
ii  ckeditor4.5.7+dfsg-2
ii  libphp-predis   0.8.3-1
ii  lighttpd [httpd]1.4.45-1
ii  php-curl1:7.0+49
ii  php-fpm 1:7.0+49
ii  php-json1:7.0+49
ii  php-pclzip  2.8.2-4
ii  php-seclib  1.0.5-1
ii  php-xml 1:7.0+49
ii  php7.0-curl [php-curl]  7.0.33-0+deb9u1
ii  php7.0-fpm [php-fpm]7.0.33-0+deb9u1
ii  php7.0-json [php-json]  7.0.33-0+deb9u1
ii  php7.0-xml [php-xml]7.0.33-0+deb9u1

rainloop recommends no packages.

Versions of packages rainloop suggests:
pn  php5-sqlite | php5-mysql | php5-pgsql  

-- Configuration Files:
/etc/rainloop/application.ini changed [not included]

-- no debconf information





Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

2018-12-31 Thread Stuart Prescott
Control: tags -1 + patch

Dear Marcus & python-debian co-maintainers,

> > If other tools/libraries are more tolerant, including python-apt,
> > would it make sense for python-debian to be more tolerant when using
> > the in-built parser? In that case, the two parser implementations
> > would be more consistent.
> 
> The problem is that iter_paragraphs is used in situations where that
> construct should be a paragraph separator, such as in debian/control.
> 
> https://bugs.debian.org/715558   (and many duplicates)
> 
> Perhaps the internal parser needs a 'strict'ness parameter that controls
> this behaviour. I'll look at that next.

Some code that:

* allows the caller to explicitly say whether whitespace-only lines delimit 
paragraphs (`whitespace-separates-paragraphs`)

* implicitly sets `whitespace-separates-paragraphs=True` if called through 
generic Deb822.iter_paragraphs (the `debian/control` / wrap-and-sort case; 
#715558)

* implicitly sets `whitespace-separates-paragraphs=False` if called through 
specific Packages.iter_paragraphs or Sources.iter_paragraphs (the emulating 
python-apt case; #913274)

https://salsa.debian.org/python-debian-team/python-debian/merge_requests/9

Comments and reviews needed!

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#917934: RM: bind-key -- ROM; binary built from another source package

2018-12-31 Thread Lev Lamberov
Package: ftp.debian.org
Severity: normal

Dear FTP Team,

since the last release of use-package [up], bind-key is built from the
use-package source package, so there's no need to have it separately.
Please, remove bind-key source package and its binary package. I've
already uploaded use-package 2.4-1, which builds elpa-bind-key and
several other binary packages.

[up] https://tracker.debian.org/pkg/use-package

Cheers!
Lev Lamberov



Bug#915187: netfilter-persistent: Updating netfilter-persistent results in error

2018-12-31 Thread gustavo panizzo

Hi

On Mon, Dec 17, 2018 at 10:01:10PM +0100, Nico Haase wrote:

Hi Gustavo,

I'm sorry, but I still don't get it completely.

Am 16.12.2018 um 02:31 schrieb gustavo panizzo:

Is not a parsing problem, the CHAINs do not exists.
You need to check your setup. Check where the ip6*tables* symlinks
points to and make it consistent.


ip6tables-save points to /usr/sbin/ip6tables-nft-save, the version 
string is ip6tables-save v1.8.2 (nf_tables). ip6tables-restore points 
to /usr/sbin/ip6tables-nft-restore, which is of the same version 
v1.8.2. I've never touched these symlinks on my own.



Also remove the legacy rules before applying new rules.

if ip{,6}tables-save and ip{,6}tables-restore dont work in your system,
netfilter-persistent won't work either (is just a wrapper around them to
start the firewall at boot time)


Yeah, and that is still my point of asking here: how can it be 
possible that dumping the rules and importing with tools from the same 
package with the same version throws an error? Shouldn't the process 
to write the rules generate a file that is sound and can be restored?




as an iptables user i know the process to save and restore is sound, but
the runtime environment (ipsets, dns resolution, kernel modules) may not
be the same when rules are saved and restored, making the restore to fail. 


This doesn't sound like your case (you are saving and loading
the rules right after) but is worth mentioning.

Is it possible that there are incompatibilities with other parts? For 
example, I'm running the kernel version 4.4.134.



I can reproduce your issues with a 4.4 kernel, but not with 4.1[8-9]
kernel.


root@testing-vm:~# ip6tables-restore < /etc/iptables/rules.v6  
ip6tables-restore v1.8.2 (nf_tables):  
line 3: CHAIN_UPDATE failed (No such file or directory): chain

PREROUTING
line 4: CHAIN_UPDATE failed (No such file or directory): chain INPUT
line 5: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT
line 6: CHAIN_UPDATE failed (No such file or directory): chain
POSTROUTING
root@testing-vm:~# cat /etc/iptables/rules.v6  
# Generated by ip6tables-save v1.6.2 on Wed Oct 24 06:16:46 2018   
*nat

:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]  
COMMIT 
# Completed on Wed Oct 24 06:16:46 2018
# Generated by ip6tables-save v1.6.2 on Wed Oct 24 06:16:46 2018   
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]   
COMMIT 
# Completed on Wed Oct 24 06:16:46 2018
root@testing-vm:~# uname -a

Bug#907592: global: gtags doesn't generate tags for R sources

2018-12-31 Thread Punit Agrawal
A pull request updating the lexer for R has been recently merged
upstream[0]. As this issue is due to incorrect parsing, it is worth
investigating whether the improved lexer helps with $SUBJECT.

[0] 
https://bitbucket.org/birkenfeld/pygments-main/pull-requests/680/slexer-improvements/diff



Bug#916933: RFS: libgsm/1.0.18-1 [ITA]

2018-12-31 Thread Felix Lechner
Hi Adam,

On Fri, Dec 21, 2018 at 11:27 AM Adam Borowski  wrote:
>
> So please give me something to re-test and upload.

Please look again on Mentors. https://mentors.debian.net/package/libgsm

> I'd be happy with either a hard break or a compat link -- it's up to you and
> your upstream wrt what is preferred.

Upstream ships the sole header in /usr/include/gsm.h.

Fedora and its derivatives, on the other hand, ship the header in
/usr/include/gsm/gsm.h and set a symlink at /usr/include/gsm.h. In
Debian, we also use those locations (it's the same file). If you have
no objections, I would like to proceed with Fedora's model.

>From my experience, most software will look at either location, or
sometimes at both. (My two packages mediastreamer2 and svxlink do.)
Also, the codec is often optional, as you already noted, and may be
omitted unless found. The upcoming release deadline is another factor.
Most people are busy with other things.

In summary: The library is over twenty-five years old; I would prefer
to accept the status quo (while fixing #882176).

On my system with the version in Mentors, these consumers built
successfully via sbuild:

asterisk
freerdp2
gmerlin-avdecoder
mediastreamer2
twinkle



Bug#917933: netdata: /var/lib/dpkg/info/netdata.postinst: 32: /var/lib/dpkg/info/netdata.postinst: Syntax error: "then" unexpected (expecting "fi")

2018-12-31 Thread Axel Beckert
Package: netdata
Version: 1.11.1+dfsg-1
Severity: serious

Upgrading netdata failed for me as follows:

Setting up netdata (1.11.1+dfsg-1) ...
Installing new version of config file /etc/init.d/netdata ...
/var/lib/dpkg/info/netdata.postinst: 32: /var/lib/dpkg/info/netdata.postinst: 
Syntax error: "then" unexpected (expecting "fi")
dpkg: error processing package netdata (--configure):
 installed netdata package post-installation script subprocess returned error 
exit status 2

Reason seems to be that lines 29 to 40 of
/var/lib/dpkg/info/netdata.postinst contain "»···" instead of a tab
character. Might be some copy & paste gone wrong.

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

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages netdata depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  init-system-helpers1.56+nmu1
ii  libc6  2.28-4
ii  libcap2-bin1:2.25-1.2
ii  libipmimonitoring6 1.5.7-2.1
ii  libuuid1   2.33-0.2
ii  lsb-base   10.2018112800
ii  netdata-data   1.11.1+dfsg-1
ii  python33.7.1-3
ii  python3-six1.12.0-1
ii  python3-urllib31.24-1
ii  python3-yaml   3.13-1
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages netdata recommends:
ii  curl7.62.0-1
ii  fping   4.1-1
ii  nodejs  8.11.2~dfsg-1

netdata suggests no packages.

-- Configuration Files:
/etc/netdata/health_alarm_notify.conf changed:
sendmail=""
curl=""
nc=""
EMAIL_SENDER=""
SEND_EMAIL="NO"
DEFAULT_RECIPIENT_EMAIL="root"
SEND_PUSHOVER="YES"
PUSHOVER_APP_TOKEN=""
DEFAULT_RECIPIENT_PUSHOVER=""
SEND_PUSHBULLET="YES"
PUSHBULLET_ACCESS_TOKEN=""
DEFAULT_RECIPIENT_PUSHBULLET=""
PUSHBULLET_SOURCE_DEVICE=""
SEND_TWILIO="YES"
TWILIO_ACCOUNT_SID=""
TWILIO_ACCOUNT_TOKEN=""
TWILIO_NUMBER=""
DEFAULT_RECIPIENT_TWILIO=""
SEND_MESSAGEBIRD="YES"
MESSAGEBIRD_ACCESS_KEY=""
MESSAGEBIRD_NUMBER=""
DEFAULT_RECIPIENT_MESSAGEBIRD=""
SEND_KAVENEGAR="YES"
KAVENEGAR_API_KEY=""
KAVENEGAR_SENDER=""
DEFAULT_RECIPIENT_KAVENEGAR=""
SEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN=""
DEFAULT_RECIPIENT_TELEGRAM=""
SEND_SLACK="YES"
SLACK_WEBHOOK_URL=""
DEFAULT_RECIPIENT_SLACK=""
SEND_ALERTA="YES"
ALERTA_WEBHOOK_URL=""
ALERTA_API_KEY=""
DEFAULT_RECIPIENT_ALERTA=""
SEND_FLOCK="YES"
FLOCK_WEBHOOK_URL=""
DEFAULT_RECIPIENT_FLOCK=""
SEND_DISCORD="YES"
DISCORD_WEBHOOK_URL=""
DEFAULT_RECIPIENT_DISCORD=""
SEND_HIPCHAT="YES"
HIPCHAT_SERVER="api.hipchat.com"
HIPCHAT_AUTH_TOKEN=""
DEFAULT_RECIPIENT_HIPCHAT=""
SEND_KAFKA="YES"
KAFKA_URL=""
KAFKA_SENDER_IP=""
SEND_PD="YES"
DEFAULT_RECIPIENT_PD=""
SEND_IRC="YES"
DEFAULT_RECIPIENT_IRC=""
IRC_NETWORK=""
IRC_NICKNAME=""
IRC_REALNAME=""
SEND_CUSTOM="YES"
DEFAULT_RECIPIENT_CUSTOM=""
custom_sender() {
# variables you can use:
# ${host}   the host generated this event
# ${url_host}   same as ${host} but URL encoded
# ${unique_id}  the unique id of this event
# ${alarm_id}   the unique id of the alarm that generated this event
# ${event_id}   the incremental id of the event, for this alarm id
# ${when}   the timestamp this event occurred
# ${name}   the name of the alarm, as given in netdata health.d 
entries
# ${url_name}   same as ${name} but URL encoded
# ${chart}  the name of the chart (type.id)
# ${url_chart}  same as ${chart} but URL encoded
# ${family} the family of the chart
# ${url_family} same as ${family} but URL encoded
# ${status} the current status : REMOVED, UNINITIALIZED, 
UNDEFINED, CLEAR, WARNING, CRITICAL
# ${old_status} the previous status: REMOVED, UNINITIALIZED, 
UNDEFINED, CLEAR, WARNING, CRITICAL
# ${value}  the current value of the alarm
# ${old_value}  the previous value of the alarm
# ${src}the line number and file the alarm has been 
configured
# ${duration}   the duration in seconds of the previous alarm state
# ${duration_txt}   same as ${duration} for humans
# ${non_clear_duration} the total duration in seconds this is/was non-clear
# ${non_clear_duration_txt} same as ${non_clear_duration} for humans
# ${units}  the units of the value
# ${info}   a short description of the alarm
# ${value_string}   friendly value (with units)
# ${old_value_string}   friendly old value (with units)
# ${image}  the 

Bug#917932: dma: no support for PLAIN authentication

2018-12-31 Thread Celejar
Package: dma
Version: 0.11-1+b1
Severity: important
Tags: upstream

Hi,

I'm trying to use dma to send mail via Zoho.com (smtp.zoho.com), but it
fails with:

smarthost authentication: AUTH cram-md5 not available: 501 Could not do Unknown 
Authentication

Apparently, dma doesn't support PLAIN authentication, and Zoho doesn't
offer any authentication protocol that it does support. There's an issue
about this upstream:

https://github.com/corecode/dma/issues/50

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
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.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dma depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  libssl1.1  1.1.1a-1
ii  ucf3.0038+nmu1

dma recommends no packages.

dma suggests no packages.

-- Configuration Files:
/etc/dma/auth.conf [Errno 13] Permission denied: '/etc/dma/auth.conf'

-- debconf information excluded



Bug#917931: /usr/bin/ibus: IBus blocks shortcuts with letter keys in Chromium

2018-12-31 Thread Minh Duc Vo
Package: ibus
Version: 1.5.19-1
Severity: normal
File: /usr/bin/ibus

Issue description :
- Chromium shortcuts with letter keys intercepted by IBus

Steps to reproduce:

- Fire up Chromium and open a random website with a text field
- Set focus on the text field or the Omnibox
- Press a Chromium shortcut that have a letter key, be it Ctrl+N, Ctrl+Shift+I,
or Ctrl+Shift+M. It won't work. However, shortcuts without a letter like
Ctrl+Tab or Ctrl+PageDown/PageUp works normally.

Can you reproduce your problem when you restart ibus-daemon?

- Yes. Identical reproduction process.

Do you see any errors when you run ibus-daemon with the verbose option?

```
(ibus-ui-gtk3:29687): IBUS-WARNING **: 09:38:02.652: panel.vala:255: If you
launch KDE5 on xterm, export XDG_CURRENT_DESKTOP=KDE before launch KDE5.

(ibus-ui-gtk3:29687): IBUS-WARNING **: 09:38:02.822: ibus_bus_call_sync:
org.freedesktop.DBus.Properties.Get:
GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine.

(ibus-ui-gtk3:29687): Gdk-CRITICAL **: 09:38:02.877:
gdk_window_thaw_toplevel_updates: assertion
'window->update_and_descendants_freeze_count > 0' failed
```

Can you reproduce your problem with a new user account instead of the current
your account? Yes




-- Package-specific info:
default-display-manager: /usr/sbin/lightdm
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l =>  ibus fcitx xim
im-config -m => default missing ibus ibus
XMODIFIERS=@im=ibus
GTK_IM_MODULE=xim
QT4_IM_MODULE=xim
QT_IM_MODULE=ibus
XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share
XDG_MENU_PREFIX=xfce-
PATH=~/bin:~/bin/simple-deodexer:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

ls -l /usr/lib/ibus/
total 992
-rwxr-xr-x 1 root root  22600 Aug 25 01:51 ibus-dconf
-rwxr-xr-x 1 root root  14408 Aug 25 01:51 ibus-engine-simple
-rwxr-xr-x 1 root root 114440 Aug  2  2016 ibus-engine-unikey
-rwxr-xr-x 1 root root 157768 Aug 25 01:51 ibus-extension-gtk3
-rwxr-xr-x 1 root root  88136 Aug 25 01:51 ibus-portal
-rwxr-xr-x 1 root root  77192 Aug  2  2016 ibus-setup-unikey
-rwxr-xr-x 1 root root 116816 Aug 25 01:51 ibus-ui-emojier
-rwxr-xr-x 1 root root 309384 Aug 25 01:51 ibus-ui-gtk3
-rwxr-xr-x 1 root root 100040 Aug 25 01:51 ibus-x11

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

Kernel: Linux 4.19.0-12.3-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ibus depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  dconf-cli0.30.1-2
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.2-3
ii  gir1.2-ibus-1.0  1.5.19-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-3
ii  libcairo21.16.0-2
ii  libdconf10.30.1-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.2-3
ii  libibus-1.0-51.5.19-1
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  librsvg2-common  2.44.10-1
ii  libx11-6 2:1.6.7-1
ii  libxi6   2:1.7.9-1
ii  python3  3.7.1-3
ii  python3-gi   3.30.4-1

Versions of packages ibus recommends:
ii  im-config   0.38-1
ii  libqt5gui5  5.11.3+dfsg-2

Versions of packages ibus suggests:
pn  ibus-clutter  
pn  ibus-doc  
pn  ibus-qt4  
ii  libqt5gui55.11.3+dfsg-2

-- no debconf information



Bug#917247: udev: Many modules are no longer automatically loaded at boot

2018-12-31 Thread gregor herrmann
On Tue, 01 Jan 2019 01:40:09 +0100, gregor herrmann wrote:

> (And with 240-2 and 2.03.02-1 there are still interaction problems

*cough*

… with udev 240-2 and lvm2 2.03.02-1 …


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Little Walter: Ah'w Baby


signature.asc
Description: Digital Signature


Bug#917622: Keyboard shortcuts ignored in text fields

2018-12-31 Thread Minh Duc Vo


On Jan 1 2019, at 7:57 am, Michael Gilbert  wrote:
> control: tag -1 moreinfo
>
> On Sat, Dec 29, 2018 at 7:27 AM Minh Duc Vo wrote:
> > Inputting a shortcut key combination while a text field is being focused 
> > will
> > not trigger the desired action for that combination.
> > For example, A Ctrl+T combination inputted while the cursor is placed in the
> > Omnibox will simply be ignored without any further effect.
>
>
> I am not able to reproduce this with the version you mention. Are you
> sure that there isn't something else interpreting key presses, perhaps
> your desktop environment or window manager?
>
> Best wishes,
> Mike
>

Okay, so, in Cinnamon, I can confirm that stopping IBus with ibus exit makes 
things turn back to normal. That also applies in Xfce4.
It looks like the problem itself doesn't come from Chromium. Sorry for 
disturbance.


Bug#917622: Keyboard shortcuts ignored in text fields

2018-12-31 Thread Michael Gilbert
control: tag -1 moreinfo

On Sat, Dec 29, 2018 at 7:27 AM Minh Duc Vo wrote:
> Inputting a shortcut key combination while a text field is being focused will
> not trigger the desired action for that combination.
> For example, A Ctrl+T combination inputted while the cursor is placed in the
> Omnibox will simply be ignored without any further effect.

I am not able to reproduce this with the version you mention.  Are you
sure that there isn't something else interpreting key presses, perhaps
your desktop environment or window manager?

Best wishes,
Mike



Bug#717563:

2018-12-31 Thread Sandro Tosi
Hey Kay,
the patch against python-debianbts has been applied and the package
uploaded: do you mind update your patch against reportbug to include
it?

thanks!

On Wed, Dec 26, 2018 at 4:16 PM Sandro Tosi  wrote:
>
> control: block -1 by 914057
>
> On Fri, Nov 30, 2018 at 9:09 PM Kay Mccormick  wrote:
> >
> > I managed to fix this (at least for the get_bugs case) but it required 
> > changes
> > to python-debianbts package.
> >
> > I have included two patches for feedback. There are some caveats:
> >
> > * Other method calls need to be patched in reportbug/debbugs.py.
> > * pysimplesoap will use alternatve http transport libraries if httplib2 is 
> > unavailable, and proxy support is unavailable for some of the other 
> > transports such as urllib2.
> > * reportbug uses urllib2 over httplib2, and pysimplesoap uses httplib2 over 
> > urllib2, but i don't think httplib2 is a dependency of reportbug - 
> > therefore, that must changed also or pysimplesoap wont pick it up.
>
> i see you opened 914057 - let's first see how the python-debianbts
> maintainer reacts (we need low-level support first anyway).
>
> Thanks,
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi



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



Bug#917247: udev: Many modules are no longer automatically loaded at boot

2018-12-31 Thread gregor herrmann
On Fri, 28 Dec 2018 20:39:46 +0100, Michael Biebl wrote:

> Am 28.12.18 um 20:19 schrieb Jamie Heilman:
> >> Please test if this problem is still reproducible with 240-2
> > still very much a problem with 240-2
> Are you using sysvinit as well?

I got the same today with 240-2 and sysvinit.

(And with 240-2 and 2.03.02-1 there are still interaction problems
[0]; not sure which of the many bugs in this area this is exactly and
which package is reponsible here)


Cheers,
gregor

[0] The initialization problems, with loads of:
WARNING: Device /dev/xxx not initialized in udev database even after waiting 
1000 microseconds.

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Aimee Mann: Fifty Years After The Fair


signature.asc
Description: Digital Signature


Bug#915831: Fwd: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure

2018-12-31 Thread Rich
-- Forwarded message -
From: Rich 
Date: Mon, Dec 31, 2018 at 8:16 AM
Subject: Re: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
To: Mo Zhou 


Heh. It being installed was not, AFAIK, a deliberate choice.

Attempting to remove it, though, looks...frought.

$ sudo apt remove -V insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
   init (1.48)
   initscripts (2.88dsf-59.9)
   insserv (1.14.0-5.4+b1)
   systemd-sysv (232-25+deb9u6)
   sysv-rc (2.88dsf-59.9)
   sysvinit (2.88dsf-59)
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
   init
   systemd-sysv (due to init)
0 upgraded, 0 newly installed, 6 to remove and 39 not upgraded.
After this operation, 735 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]

I'm reasonably confident doing this will break any sort of sysvinit
script usage on the whole system, which (presumably) would defeat the
purpose of ever shipping the sysvinit scripts?

It seems like what we might want is an OR dependency on two child
zfs-{systemd,sysvinit} packages - and for those two packages to
conflict with each other (and require the appropriate respective init
packages)? I think that's the right dependency interlock - exactly one
of {zfs-sysvinit,zfs-systemd} installed with the zfsutils-linux
package, probably with Breaks (zfsutils-linux < $NEW_SHINY_VERSION) in
the new children so that zfsutils-linux's new version shows up first,
and we don't have the two new packages trying to step on the old one's
files?

I don't actually know what a "reasonable" Debian system still using
sysvinit and not transitional bits looks like, so I don't know ATM how
to express the appropriate kind of conflict, but since I think(?) it's
still reasonable to have sysvinit compat hooks installed on stretch,
and I think it's also reasonable to not force people to remove all
sysvinit compat packages to install zfsutils-linux, it seems like
breaking the mutually exclusive bits out might be the best option?

(I think there's also a way to just do this with one new sysvinit
child package, that diverts all the systemd service scripts to
/dev/null or similar when it's installed and reverts it when not, but
since it's not clear to me that it'd be simpler to do that,
particularly if you're still having to include enumeration of the
systemd service files you're overriding in the sysvinit package, I
started with breaking them both out.)

Does that all make sense and/or seem correct? I don't think I made any
unreasonable assumptions about what a "correct" transition path to
having sysvinit and/or systemd files around given the prior states and
that having both enabled is probably impractical, but please tell me
if my pants are on my head. :)

(Also, thanks a lot for spending the time digging into this, I had
been hoping to doso over my short winter vacation, but other things
topped the priority queue.)

- Rich

On Mon, Dec 31, 2018 at 5:28 AM Mo Zhou  wrote:
>
> Hi Rich,
>
> I investigated into this issue a bit and it looks like a result of
> messy system where systemd-sysv and insserv are co-installed.
> In insserv/sid, the postinst process will nolonger fail even if the
> same error occurs. The error will disappear if you remove insserv.
> And in your initial bug report, meta infomation told me that you
> use systemd. So please don't co-install systemd-sysv and insserv.
>
> From zfs's side we can do mostly nothing to prevent user from
> co-installing systemd-sysv and insserv, except for a simple
> suggestion.
>
> Does the issue you reported persist even after removing insserv?
>
>
>
> I tried to install zfs tens of times in different virtual machines
> setup in differrent settings. And my conclusion is simply don't
> co-install them.



Bug#917874: /etc/init.d/apparmor: 60: shift: can't shift that many

2018-12-31 Thread gregor herrmann
On Mon, 31 Dec 2018 13:04:59 +0100, Jakub Wilk wrote:

> Now I get:
> 
>   Starting AppArmor - failed, To enable AppArmor, ensure your kernel is 
> configured with CONFIG_SECURITY_APPARMOR=y then add 'security=apparmor 
> apparmor=1' to the kernel command line

That's what I got as well today after a reboot. Makes apparmor pretty
unusable …
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Tracy Chapman: You're The One


signature.asc
Description: Digital Signature


Bug#547608: better URLs for policy doc

2018-12-31 Thread 積丹尼 Dan Jacobson
OK looking at the bug, that was nine years ago.
I am sure you have a better grasp of the current situation so
closing the bug is fine.



Bug#914886: chromium: SafeBrowsing is not working at all (sample included)

2018-12-31 Thread Michael Gilbert
control: tag -1 moreinfo

On Wed, Nov 28, 2018 at 4:09 AM Peter Gervai wrote:
> Anyway, Chromium SafeBrowsing seems not to work at all, despite that both
> "SafeBrowsing" and "Help improve SB" is on.
>
> Just go to this URL and see no warnings: 
> https://www[.]xn--bbox-vw5a[.]com/login
> (It is a phishing site for bibox.com with TLS domain padlock.)
> The URL is detected by both FireFox and Google SafeBrowsing website.

I tried this both with and without safe browsing enabled in chromium
72.  It always detected the site as insecure, the red Not Secure
triangle, regardless of the safebrowsing setting.  Maybe this was a
temporary bug in version 70?  Could you retest with a newer version?

Best wishes,
Mike



Bug#915344: openfoam: diff for NMU version 4.1+dfsg1-2.3

2018-12-31 Thread Anton Gladky
Hello Adrian,

thank you for the patch! Feel free to put the NMU-upload
into the DELAYED/0.

Regards

Anton

Am Mo., 31. Dez. 2018 um 16:39 Uhr schrieb Adrian Bunk :
>
> Control: tags 915344 + patch
> Control: tags 915344 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for openfoam (versioned as 4.1+dfsg1-2.3) and
> uploaded it to DELAYED/14. Please feel free to tell me if I should
> cancel it.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers



Bug#917930: file: missing dependency: libseccomp-dev

2018-12-31 Thread testuser524
Package: file
Version: 1:5.34-2
Severity: normal

Dear Maintainer,

the current package for the program file as shipped with debian testing and 
newer 
includes a statement in the manpage about file being sandboxed by default using 
libseccomp.

However since libseccomp-dev is not included in the build dependencies, this 
feature is not included.

This can be tested by running "ldd /usr/bin/file" which will not list 
libseccomp-dev as a linked library.
Building file on a system with libseccomp-dev available solves this issue.

Since this sandbox feature might cause issues with other applications running 
file with the decompression
option -z but without the new -S option to disable seccomp, having this feature 
enabled like upstream indended
might cause issues.

The correct way to handle those issues would be to fix third party applications 
that use file incorrectly 
(without -S for decompression), however other distributions like arch have 
instead disabled seccomp support in file.

In case you decide to do the same please remove the statement in the manpage 
that file runs with seccomp by default.



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

Kernel: Linux 4.19.0-1-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages file depends on:
ii  libc6  2.28-2
ii  libmagic1  1:5.34-2
ii  zlib1g 1:1.2.11.dfsg-1

file recommends no packages.

file suggests no packages.

-- no debconf information



Bug#916725: chromium: Extensions which access Google Bookmarks fail

2018-12-31 Thread Michael Gilbert
control: severity -1 normal

On Mon, Dec 17, 2018 at 4:15 PM Sean Shapira wrote:
> Extensions which attempt to access Google (not chrome) bookmarks no longer
> function. This is a regression introducted since 69.0.3497.92-1~deb9u1.

enable_one_click_signin is set to false starting with version 70 to
prevent background interfacing with google services.  It is the most
likely cause here.  Other users expect chromium to not interface with
google's services, so you would need to debate them about whether or
not this should be enabled.  I am inclined to leave it disabled.

Best wishes,
Mike



Bug#917928: libsensors5-dev seems to be missing, only libsensors4-dev is there in buster

2018-12-31 Thread Nerdopolis Turfwalker
Package: libsensors5
Severity: normal

Dear Maintainer,

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

I am trying to install libsensors5-dev but all that is there is libsensors4-dev
It also seems that there is a conflict between libsensors4 and 5, and one of 
the 
packages depends on the other as well

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


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

Kernel: Linux 4.19.0-1-686-pae (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsensors5 depends on:
ii  libc6  2.28-2
pn  libsensors-config  

libsensors5 recommends no packages.

Versions of packages libsensors5 suggests:
pn  lm-sensors  



Bug#917929: lightdm: multiseat causes ghost-logins

2018-12-31 Thread westlake

Package: lightdm
Version: 1.18.3-1
Severity: important

Multi-seat works perfectly up to the point which I decribe below.

There are existing users who do not login who automatically appear to 
login onto the workstation.

(no remote services -- it's not a compromised system)

loginctl
SESSION  UID USERSEAT   TTY
  145180 root
   8901 1000 userA   seat0
c14  131 lightdm seat0
c33  131 lightdm seat-1


Even after clearing the logged-in users (there's only about 2 or 3 users 
on this system.. ) , with loginctl terminate-user ...  a user or two 
then re-appear again...


ps shows gvfs things.

I looked at timers with systemctl list-timers and disabled/stopped any 
of them.


I also tried to look at timers with user accounts using, "systemctl 
--user" list-timers and couldn't find anything under there.


I wonder what is "triggering" these processes...

it must be a bug lightdm.

/etc/lightdm/lightdm.conf

[Seat:seat0]
logind-check-graphical=true
type=xlocal

#xserver-config=/etc/X11/xorg.conf.intel_seat0
#note: debian's current Xorg (in this system), manpage does not indicate 
-seat seat_id but Xorg --help shows it is available


xserver-config=/etc/X11/xorg.conf.seat0
xserver-command=/usr/bin/Xorg -nolisten tcp -layout layout_seat0 -seat 
seat0 -novtswitch



[Seat:seat-1]
logind-check-graphical=true
type=xlocal

xserver-config=/etc/X11/xorg.conf.seat-1
xserver-command=/usr/bin/Xorg -nolisten tcp -layout layout_seat-1 -seat 
seat-1 -novtswitch


-

I provided xserver-config for the two seats, there's nothing special I 
can find which can be triggering this...


Despite the multiple ghost-logins, I am able to login via lightdm with 
the already listed users shown with loginctl list-users.



-Scott

Section "ServerLayout"
Identifier "layout_seat-1"
MatchSeat "seat-1"

Screen  0  "Screen0" 
InputDevice"Mouse0" 
InputDevice"Keyboard0" 

Option "SingleCard" "on"

EndSection

Section "ServerFlags"
 Option "DefaultServerLayout" "layout_seat-1"
 Option "AllowMouseOpenFail" "true"
 Option "AutoAddDevices" "false"
 Option "Xinerama" "false"

EndSection

Section "InputDevice"
   Identifier  "Keyboard0"
   # Driver  "kbd"
  Driver  "evdev"
  Option "GrabDevice" "on"
   Option "Device" "/dev/input/by-id/usb-Darfon_USB_Combo_Keyboard-event-kbd"

   Option "XkbRules" "base"
   Option "XkbModel" "pc105"
   Option "XkbLayout" "us"

   Option "CoreKeyboard" "on"

EndSection

Section "InputDevice"
Identifier  "Mouse0"
   # Driver  "mouse"
Driver "evdev"
Option "GrabDevice" "on"
Option  "Protocol" "auto"

Option "Device" 
"/dev/input/by-id/usb-Logitech_G400s_Optical_Gaming_Mouse-event-mouse"
Option "CorePointer" "on"

EndSection

Section "Monitor"
Identifier   "Monitor_BL"
VendorName   "Acer"
ModelName"1201(BL)"
EndSection


Section "Device"
Identifier  "Card0"
Driver  "nouveau"
BusID   "PCI:1:0:0"

  Option "Monitor-HDMI-A-2" "Monitor_BL"

EndSection


Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor_BL"
SubSection "Display"
Viewport   0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection


Section "ServerLayout"
Identifier "layout_seat0"
MatchSeat "seat0"

Screen  0  "Screen0" 

InputDevice"Keyboard0" 
InputDevice"Mouse0" 


Option "SingleCard" "on"

EndSection

Section "ServerFlags"
 Option "DefaultServerLayout" "layout_seat0"
 Option "AllowMouseOpenFail" "true"
 Option "AutoAddDevices" "false"
 Option "Xinerama" "false"

EndSection

Section "InputDevice"
   Identifier  "Keyboard0"
   # Driver  "kbd"
Driver  "evdev"
Option "GrabDevice" "on"
# prevent send event to other X-servers

   Option "Device" "/dev/input/by-id/usb-Microsoft_Wired_Keyboard_600-event-kbd"

   Option "XkbRules" "base"
   Option "XkbModel" "pc105"
   Option "XkbLayout" "us"

   Option "CoreKeyboard" "on"

EndSection

Section "InputDevice"
Identifier  "Mouse0"
   # Driver  "mouse"
Driver "evdev"
Option "GrabDevice" "on"
Option  "Protocol" "auto"

 Option "Device" 
"/dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse"


Bug#913978: is not accessible with Orca screenreader

2018-12-31 Thread Jeremy Bicha
Control: forwarded -1
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/327

On Sat, Nov 17, 2018 at 4:03 PM Mika Hanhijärvi  wrote:
> This is wery severe unacceptable problem. This bug makes Gnome 3.30 unusable
> for the visually impaired users because you can not access or change the
> desktop settings.

Thank you for taking the time to report this bug.

I agree that the GNOME Settings app has many accessible problems for
navigating with only a keyboard and screen reader.

I opened a bug now for the most critical issue. When that's fixed, you
should be able to navigate most of the Settings app, although there
are some elements that are not read and the context may be unclear.

Thanks,
Jeremy Bicha



Bug#916846: [libreoffice-ogltrans] Blank screen with OpenGL transitions

2018-12-31 Thread Rene Engelhard
clone 916846 -1
fixed 916846 1:6.1.4-2
reassign -1 libreoffice-impress
severity -1 important
retitle -1 [libreoffice-impress] Blank screen with OpenGL transitions
found -1 1:6.1.4-2
thanks

Hi,

On Wed, Dec 19, 2018 at 07:08:13PM +0100, Rene Engelhard wrote:
> Maybe we should just stop shipping them, no one needs it.

OK, so I merged -ogltrans back into -impress. That makes this bug
a) "fixed" in 1:6.4.1-2 of libreoffice-ogltrans (as it's now
   a transitional package and doesn't contain anything)
b) only "important", since it definitely doesn't make the whole
   of Impress unusable but just affects the OpenGL transitions thingy.


Yes, this is an "evil" trick to make this bug not RC anymore...


If someone finds the cause of this it can and will be fixed, though.

Regards,
 
Rene



Bug#917875: RFS: fathom/1.0-1 [ITP]

2018-12-31 Thread Pierre-Elliott Bécue
Le lundi 31 décembre 2018 à 10:46:20+0100, Jose G. López a écrit :
> On Mon, 31 Dec 2018 10:35:55 +0100
> "Jose G. López"  wrote:
> 
> > P.D: It's a requirement for ethereal-chess (ITP #914595) and surely for 
> > other
> > chess engines that are embedding this probe tool.
> > 
> 
> Sorry ITP actually is 914598.

Hi,

I suggest you rename your branch "master" to "upstream".

Regardless:

 * d/patches: why changing the .c file instead of adding -I to gcc calls?

Otherwise, LGTM, I'll upload as soon as you answer. :)

Thanks,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature


Bug#917925: Module fails to load on Linux 4.3 or later

2018-12-31 Thread Guillem Jover
Hi!

On Mon, 2018-12-31 at 19:51:39 +, Ben Hutchings wrote:
> Package: device3dfx-source
> Version: 2013.08.08-6
> Severity: grave
> 
> devie3dfx-source can now build a module, but with these build-time
> warnings:
> 
>   MODPOST 1 modules
> WARNING: "mtrr_del" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!
> WARNING: "mtrr_add" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!
> 
> The mtrr_{add,del}() functions are no longer exported since Linux 4.3,
> which means it won't be possible to load the module.  Drivers should
> use the higher-level functions arch_phys_wc_{add,del}() to mark memory
> as write-combining.

Ah, thanks, I had completely forgotten about this, which looks like I
had fixed locally back in August! I think I got more concerned on
whether the upload would get through at all, due to the new dpkg-dev
code I used which omits the Binary and Description fields on the
.changes file, than on the build output here. :)

Will roll out a new upstream release and upload a new version.

Thanks,
Guillem



Bug#893814: keyboard-configuration: Set the default XKB model to nokiarx51 for Nokia N900 devices

2018-12-31 Thread David Derby

Dear maintainer,

Is there any chance of getting this patch merged before the buster 
transition freeze on 2019-01-12?  It would be a shame to miss the 
release and have to wait an additional 2 years for this to be included 
in Debian stable (bullseye).  Is there anything I can do to help with 
this?


I look forward to hearing from you.

Kind regards,

David



Bug#917926: RFS: openbox/3.6.1-8

2018-12-31 Thread Mateusz Łukasik

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: openbox
   Version : 3.6.1-8
   Upstream Author : Dana Jansens 
 * URL : openbox.org
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

gnome-panel-control - command line utility to invoke GNOME panel run 
dialog/menu
 libobrender32v5 - rendering library for openbox themes
 libobt2v5  - parsing library for openbox
 openbox- standards-compliant, fast, light-weight and extensible window man
 openbox-dev - development files for the openbox window manager
 openbox-gnome-session - command line utility to run Openbox as GNOME session
 openbox-kde-session - command line utility to run Openbox as KDE SC session

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/o/openbox/openbox_3.6.1-8.dsc


  Changes since the last upload:

  * Fix applications menu when there are no entries.
(Closes: #888254 #887122 #886716) (LP: #1771696).
  * debian/control:
+ Add obconf-qt as alternative for obconf. (Closes: #914960)
+ Bump Standards-Version to 4.3.0.
+ Remove openbox-menu from Recommends. (Closes: #876017)
  * debian/docs/build.html drop suggests using non-existent kdetrayproxy.
(Closes: #916086)
  * debian/patches:
+ Add 917204_undecorated_maximized_no_border.patch for removed top
border on undecorated maximized windows. (Closes: #917204)

  Regards,
   Mateusz Łukasik



Bug#913663: Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

2018-12-31 Thread gregor herrmann
Control: retitle 917592 libterm-termkey-perl: FTBFS with STDIN as a readable 
non-tty
Control: severity 917592 important
Control: retitle 917497 libanyevent-termkey-perl: FTBFS with STDIN as a 
readable non-tty
Control: severity 917497 important

On Sun, 30 Dec 2018 20:22:00 +, Niels Thykier wrote:

> gregor herrmann:
> > Results for the various option in override_dh_auto_test:
> 
> Basically, the test (t/05flags.t) seg. faults if stdin is a *readable*
> non-tty (but succeeds in all other cases).

Ah ok, thanks.
 
> My recommendation is to use a short term work around by replacing the
> dh_auto_test call with the upstream test runner.  This will take the
> "edge" off this bug and enable us to debug this issue without the same
> pressure with the upcoming freeze.

Agreed. I've uploaded libterm-termkey-perl and
libanyevent-termkey-perl earlier today with a workaround.
 
> Anyhow, on to the details I have found:

Thanks for your debugging, and also to James for his help.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: B.B. King and Eric Clapton


signature.asc
Description: Digital Signature


Bug#917607: udev 240 Makes System Unbootable; rootfs Not Found

2018-12-31 Thread Leo L. Schwab
On Sun, Dec 30, 2018 at 10:36:02PM +0100, Michael Biebl wrote:
> Can you share more details about your storage configuration, like mdadm
> configs, /etc/fstab etc.
> 
Oh, sorry, left out partition info.

/etc/fstab by itself won't make much sense, as it's all UUIDs.
Further, the system dual-boots Win7 and Linux, spending most of its time in
the latter.

This will probably be more useful to you:


$ sudo lsblk -f
NAME   FSTYPE LABEL UUID FSAVAIL FSUSE% 
MOUNTPOINT
sda 
├─sda1 vfat ECB5-32D4  77.8M19% 
/boot/efi
├─sda2  
├─sda3 ntfs 143EEC7D3EEC58EE
├─sda4 ext4   debian-rootfs eb6ceb17-4ec4-4388-a902-ff2699840d62 40G31% 
/
├─sda5 ntfs   Swap  869E24439E242E5D
├─sda6 swap 8af77582-3df1-4960-a966-99388cd57906
[SWAP]
└─sda7 ext4 ce37c7e7-ba53-4151-9be2-bd9d7adb4626   65.7G 0% 
/extra
sdb 
├─sdb1  
├─sdb2 ntfs   Neptune   6018A6CC18A6A090
└─sdb3 ext4   mnt.home  5f8a63b0-12f0-4041-84b3-8235ded4b51a  857.2G 6% 
/home
sdc 
├─sdc1 ext4   vidwork   38fde8c7-11ed-48df-996e-08ffdef5434b  173.7G49% 
/vidwork
├─sdc2  
└─sdc5 ntfs   Re-lantic A6B87CCFB87C9F8B
sr0 


Mapped as follows:

/dev/sda3 -- Windows C:\ volume
/dev/sda4 -- Linux rootfs.
/dev/sda5 -- Windows swap (swapfile.sys is forced here).
/dev/sda6 -- Linux swap.
/dev/sda7 -- ext4 filesystem.

/home lives on /dev/sdb3.

Schwab



Bug#917911: libdatetime-timezone-perl 2.09-1+2018i flagged for acceptance

2018-12-31 Thread Adam D Barratt
Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian .

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.09-1+2018i

Explanation: update included data



Bug#917377: tar: diff for NMU version 1.30+dfsg-3.1

2018-12-31 Thread Salvatore Bonaccorso
Control: tags 917377 + patch
Control: tags 917377 + pending


Hi Bdale,

I've prepared an NMU for tar (versioned as 1.30+dfsg-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

What do you think on the update? Are you fine with the NMU or would
you like rather to do a maintainer update as you know best if you want
to include more for buster? I have seen there is one further RC
severity bug for tar which is affecting the upcoming stable release so
far. But I adressed only specifically #917377 here.

Regards,
Salvatore
diff -Nru tar-1.30+dfsg/debian/changelog tar-1.30+dfsg/debian/changelog
--- tar-1.30+dfsg/debian/changelog	2018-11-17 08:33:47.0 +0100
+++ tar-1.30+dfsg/debian/changelog	2018-12-31 21:08:52.0 +0100
@@ -1,3 +1,11 @@
+tar (1.30+dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Infinite read loop in sparse_dump_region function (CVE-2018-20482)
+(Closes: #917377)
+
+ -- Salvatore Bonaccorso   Mon, 31 Dec 2018 21:08:52 +0100
+
 tar (1.30+dfsg-3) unstable; urgency=medium
 
   * elide reference to non-existent section 5 page from section 1 tar manpage,
diff -Nru tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch
--- tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch	1970-01-01 01:00:00.0 +0100
+++ tar-1.30+dfsg/debian/patches/Fix-CVE-2018-20482.patch	2018-12-31 21:08:52.0 +0100
@@ -0,0 +1,377 @@
+From: Sergey Poznyakoff 
+Date: Thu, 27 Dec 2018 17:48:57 +0200
+Subject: Fix CVE-2018-20482
+Origin: https://git.savannah.gnu.org/cgit/tar.git/commit/?id=c15c42ccd1e2377945fd0414eca1a49294bff454
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-20482
+Bug: https://lists.gnu.org/archive/html/bug-tar/2018-12/msg00023.html
+Bug-Debian: https://bugs.debian.org/917377
+
+* NEWS: Update.
+* src/sparse.c (sparse_dump_region): Handle short read condition.
+(sparse_extract_region,check_data_region): Fix dumped_size calculation.
+Handle short read condition.
+(pax_decode_header): Fix dumped_size calculation.
+* tests/Makefile.am: Add new testcases.
+* tests/testsuite.at: Likewise.
+
+* tests/sptrcreat.at: New file.
+* tests/sptrdiff00.at: New file.
+* tests/sptrdiff01.at: New file.
+---
+ NEWS|  8 +-
+ src/sparse.c| 50 +++-
+ tests/Makefile.am   |  5 +++-
+ tests/sptrcreat.at  | 62 +
+ tests/sptrdiff00.at | 55 
+ tests/sptrdiff01.at | 55 
+ tests/testsuite.at  |  5 +++-
+ 7 files changed, 231 insertions(+), 9 deletions(-)
+ create mode 100644 tests/sptrcreat.at
+ create mode 100644 tests/sptrdiff00.at
+ create mode 100644 tests/sptrdiff01.at
+
+diff --git a/src/sparse.c b/src/sparse.c
+index d41c0eacd1f3..f611200a2fc5 100644
+--- a/src/sparse.c
 b/src/sparse.c
+@@ -427,6 +427,30 @@ sparse_dump_region (struct tar_sparse_file *file, size_t i)
+ 			 bufsize);
+ 	  return false;
+ 	}
++  else if (bytes_read == 0)
++	{
++	  char buf[UINTMAX_STRSIZE_BOUND];
++	  struct stat st;
++	  size_t n;
++	  if (fstat (file->fd, ) == 0)
++	n = file->stat_info->stat.st_size - st.st_size;
++	  else
++	n = file->stat_info->stat.st_size
++	  - (file->stat_info->sparse_map[i].offset
++		 + file->stat_info->sparse_map[i].numbytes
++		 - bytes_left);
++	  
++	  WARNOPT (WARN_FILE_SHRANK,
++		   (0, 0,
++		ngettext ("%s: File shrank by %s byte; padding with zeros",
++			  "%s: File shrank by %s bytes; padding with zeros",
++			  n),
++		quotearg_colon (file->stat_info->orig_file_name),
++		STRINGIFY_BIGINT (n, buf)));
++	  if (! ignore_failed_read_option)
++	set_exit_status (TAREXIT_DIFFERS);
++	  return false;
++	}
+ 
+   memset (blk->buffer + bytes_read, 0, BLOCKSIZE - bytes_read);
+   bytes_left -= bytes_read;
+@@ -464,9 +488,9 @@ sparse_extract_region (struct tar_sparse_file *file, size_t i)
+ 	  return false;
+ 	}
+   set_next_block_after (blk);
++  file->dumped_size += BLOCKSIZE;
+   count = blocking_write (file->fd, blk->buffer, wrbytes);
+   write_size -= count;
+-  file->dumped_size += count;
+   mv_size_left (file->stat_info->archive_file_size - file->dumped_size);
+   file->offset += count;
+   if (count != wrbytes)
+@@ -598,6 +622,12 @@ check_sparse_region (struct tar_sparse_file *file, off_t beg, off_t end)
+ 			 rdsize);
+ 	  return false;
+ 	}
++  else if (bytes_read == 0)
++	{
++	  report_difference (file->stat_info, _("Size differs"));
++	  return false;
++	}
++  
+   if (!zero_block_p (diff_buffer, bytes_read))
+ 	{
+ 	  char begbuf[INT_BUFSIZE_BOUND (off_t)];
+@@ -609,6 +639,7 @@ check_sparse_region (struct tar_sparse_file *file, off_t beg, off_t end)
+ 
+   beg += bytes_read;
+ }
++
+   return true;
+ }
+ 
+@@ -635,6 +666,7 @@ check_data_region 

Bug#914694: [Pkg-utopia-maintainers] Bug#914694: firewall-cmd --reload fails: RULE_REPLACE failed (No such file or directory): rule in chain {INPUT, OUTPUT}

2018-12-31 Thread Sunil Mohan Adapa
On Tue, 27 Nov 2018 14:29:40 -0500 Eric Garver  wrote:
[...]
> That makes it smell like an iptables-restore issue in the nftables
> backed version of iptables. It would be great if we could reproduce
> without firewalld using iptables-restore.

A much simpler way I reproduced the problem with iptables-restore:

# iptables-restore <

signature.asc
Description: OpenPGP digital signature


Bug#895061: status update

2018-12-31 Thread Nicolas Boulenguez
The suggested patch for #895659 has been applied,
and you have fixed lintian.
The only blocker is now #877267 in ocaml.
While waiting for an answer, I suggest the attached change to the
manual page.
diff --git a/debhelper.pod b/debhelper.pod
index acee4e20..ddc60878 100644
--- a/debhelper.pod
+++ b/debhelper.pod
@@ -185,13 +185,10 @@ process the rest of packages with default settings.
 
 =item B<--ignore=>I
 
-Ignore the specified file. This can be used if F contains a debhelper
-config file that a debhelper command should not act on. Note that
-F, F, and F can't be ignored, but
-then, there should never be a reason to ignore those files.
-
-For example, if upstream ships a F that you don't want
-B to install, use B<--ignore=debian/init>
+The removal of this option is planned.  If you cannot acheive your
+goal with L or executable debhelper configuration files,
+please describe your needs at
+L.
 
 =item B<-P>I, B<--tmpdir=>I
 


Bug#917479: Removed package(s) from unstable

2018-12-31 Thread Scott Kitterman
You can find information on the Debian maintainer/uploaders at 
https://tracker.debian.org/pkg/foxyproxy .  I would get in touch with them.

Scott K



Bug#917925: Module fails to load on Linux 4.3 or later

2018-12-31 Thread Ben Hutchings
Package: device3dfx-source
Version: 2013.08.08-6
Severity: grave

devie3dfx-source can now build a module, but with these build-time
warnings:

  MODPOST 1 modules
WARNING: "mtrr_del" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!
WARNING: "mtrr_add" [/usr/src/modules/device3dfx/kbuild/3dfx.ko] undefined!

The mtrr_{add,del}() functions are no longer exported since Linux 4.3,
which means it won't be possible to load the module.  Drivers should
use the higher-level functions arch_phys_wc_{add,del}() to mark memory
as write-combining.

Ben.

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

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

Versions of packages device3dfx-source depends on:
ii  debhelper 12
ii  make  4.2.1-1.2
ii  module-assistant  0.11.10

Versions of packages device3dfx-source recommends:
ii  kernel-package  13.018+nmu1

device3dfx-source suggests no packages.



Bug#833116: fgetty: Incorrect keystroke interpretation

2018-12-31 Thread Ricardo Peliquero
Dmitry Bogatov  Sat, 29 Dec 2018 18:33:11 +:

> Could you try replace calls to `setlocale(LC_ALL, "")` in previous
> patch with (different variants)

>  * setlocale(LC_ALL, "C.UTF-8")

Does not work (patch applies ok but won't be able to type 'ñandú').


>  * setenv("LANG", "C.UTF-8", 1)

It works as a breeze.
Able to type 'ñandú' and other stuff with LANG=C.UTF-8.
I can always put LANG=es_AR.UTF-8 and LANGUAGE=es_AR:es into .rcrc in
order to fit my local needs, and it still works perfectly well.


>  * setenv("LC_ALL", "C.UTF-8", 1)

It works, but LC_ALL variable might not be neccessary here. I'll of
course respect your choice.

 
> Also, could you please use unified diffs (diff -U) -- they are easier
> to read? Thank you.

Certainly; suggestion appreciated.


Thank you very much, and happy new year!



Bug#917479: Removed package(s) from unstable

2018-12-31 Thread brent s.
Hey all -

Recent versions of FoxyProxy are indeed compatible with Firefox >= 57.
The source has moved to https://code.getfoxyproxy.org/ (specifically, to
https://code.getfoxyproxy.org/Foxyproxy_Firefox_Webextensions/).

Who was previously maintaining this package? Is there anyone we
can/should get in contact with to bring this up to speed?

-- 
brent s.
Linux System Administrator/Engineer
FoxyProxy (https://getfoxyproxy.org)



signature.asc
Description: OpenPGP digital signature


Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

2018-12-31 Thread Thomas Dickey
On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> * Thomas Dickey  [2018-12-31 00:51]:
> 
> > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > ...
> >> This is the behaviour I get across xterm versions:
> >> (everything with libfontconfig1 2.13.1-2)
> >> 
> >> fonts.conf enabled:
> >> 337: works
> >> 338: segfault
> >> 340: segfault
> >> 341: segfault
> > 
> > Can you make a backtrace for #341, please?
> 
> Here it is:

thanks.  I added some notes, but have not been able to reproduce the problem.
 
> Reading symbols from /usr/bin/xterm...Reading symbols from 
> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
> done.
> (gdb) run -fa 'Noto Mono'

fwiw, my Debian/testing machine has these fonts (with "noto" in their names):

ii  fonts-noto20181130-1
all  metapackage to pull in all Noto fonts
ii  fonts-noto-cjk1:20170601+repack1-3  
all  "No Tofu" font families with large Unicode coverage (CJK 
regular and bold)
ii  fonts-noto-color-emoji0~20180810-1  
all  color emoji font from Google
ii  fonts-noto-hinted 20181130-1
all  "No Tofu" font families with large Unicode coverage 
(hinted)
ii  fonts-noto-mono   20181130-1
all  "No Tofu" monospaced font family with large Unicode 
coverage
ii  fonts-noto-unhinted   20181130-1
all  "No Tofu" font families with large Unicode coverage 
(unhinted)

> Starting program: /usr/bin/xterm -fa 'Noto Mono'
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
> p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
> (gdb) bt full
> #0  0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
> p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
> v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i = 
> 1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, 
> c = 0x556f1ad0, f = 0x556f1ad0, 
> l = 0x556f1ad0, r = 0x556f1ad0}}
> vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
> c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
> vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
> c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
> vle = 
> vre = 
> m = 
> str = 
> op = 

If "op" weren't optimized, we could see which case is breaking :-)
But since "e" is null, that says op is garbage anyway.

> buf1 = {u = {d = 0, i = 0, l = 0, 
> c = 
> "\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
>  '\000' , 
> "\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
> buf2 = {u = {d = 0, i = 0, l = 0, 
> c = 
> "\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
>  '\000' , "\a\000\000\000\000\000\000\000 
> \000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
>  '\000' , "[\000\000\000w", '\000' , 
> "n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
>  '\000' , "\260\377\377\377\377\377\377\377"...}}
> #1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430, 
> p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont, 
> e=e@entry=0x55681218) at fccfg.c:1003
> m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx = 
> 1.4821969375237396e-323, yy = 1}
> xx = 
> yy = 
> xy = 
> yx = 
> v = {type = FcTypeMatrix, u = {s = 0x3  at address 0x3>, i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, 
> f = 0x3, l = 0x3, r = 0x3}}
> vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", 
> i = 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 
> 0x556f24b0, c = 0x556f24b0, f = 0x556f24b0, 


Bug#878890: fails to detect disks/partitions correctly

2018-12-31 Thread Daniel Baumann
close 878890 1.11.1+dfsg-1~exp1
thanks

Hi,

I tried to reproduce this with 1.11.1 and see, that on different systems
I see all the same filesystems information/graphs listet, with or
without the systemd unit changes.

I conclude that the bug has been fixed upstream and therefore close the bug.

Regards,
Daniel



Bug#916654: Acknowledgement (vdr-plugin-epgsearch 2.2.0+git20170817-2)

2018-12-31 Thread klak
Am Sun, 23 Dec 2018 22:55:09 +0100
schrieb klak :

> Hallo Maintainer,
> 
> after two days (of updates) the bug was gone.
> 
> Please close bug#916654.
> 
> Greets klak


Hello Maintainer,

please reopen the bug, the error occurs again.

Greets klak



Bug#810548: xserver-xorg-video-radeon: gpu lockup and black screen

2018-12-31 Thread Alexandros Prekates
Package: xserver-xorg-video-radeon
Version: 1:7.8.0-1+b1
Followup-For: Bug #810548

Dear Maintainer,

I have an radeon HD 5750

In phenomenicaly random moment ,  in frequency of one per day , and usually
while i play in the same time Stellaris (starting it from withing the steam
client)
linux will freeze and screen will become blank .Fans are still operational ,
also i tested another screen but still blank.

/var/log/syslog display hundred times :

ec 31 17:56:28 enous kernel: [20887.723072] radeon :01:00.0: GPU lockup
(current fence id 0x007c89d8 last fence id 0x007c89e0 on ring
0)
Dec 31 17:56:29 enous kernel: [20888.234984] radeon :01:00.0: ring 0
stalled for more than 216576msec
Dec 31 17:56:29 enous kernel: [20888.234987] radeon :01:00.0: GPU lockup
(current fence id 0x007c89d8 last fence id 0x007c89e0 on ring
0)
Dec 31 17:56:29 enous kernel: [20888.746986] radeon :01:00.0: ring 0
stalled for more than 217088msec


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Juniper PRO [Radeon HD 5750] [1002:68be]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-7-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 45343 Nov  2 13:41 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 46137 Dec 31 18:19 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 2.931] (--) Log file renamed from "/var/log/Xorg.pid-653.log" to 
"/var/log/Xorg.0.log"
[ 2.933] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[ 2.933] X Protocol Version 11, Revision 0
[ 2.933] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[ 2.933] Current Operating System: Linux enous 4.9.0-7-amd64 #1 SMP Debian 
4.9.110-3+deb9u2 (2018-08-13) x86_64
[ 2.933] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-7-amd64 
root=UUID=f92aef31-d231-4b0f-8d17-f120b6ec98f5 ro quiet
[ 2.933] Build Date: 03 November 2018  03:09:11AM
[ 2.933] xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support) 
[ 2.933] Current version of pixman: 0.34.0
[ 2.933]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 2.933] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 2.933] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 31 18:19:28 
2018
[ 2.937] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 2.938] (==) No Layout section.  Using the first Screen section.
[ 2.938] (==) No screen section available. Using defaults.
[ 2.938] (**) |-->Screen "Default Screen Section" (0)
[ 2.938] (**) |   |-->Monitor ""
[ 2.939] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 2.939] (==) Automatically adding devices
[ 2.939] (==) Automatically enabling devices
[ 2.939] (==) Automatically adding GPU devices
[ 2.939] (==) Max clients allowed: 256, resource mask: 0x1f
[ 2.942] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 2.942]Entry deleted from font path.
[ 2.946] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 2.946] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 2.946] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 2.946] (II) Loader magic: 0x5642f9cdbe00
[ 2.946] (II) Module ABI versions:
[ 2.946]X.Org ANSI C Emulation: 0.4
[ 2.946]X.Org Video Driver: 23.0
[ 2.946]X.Org XInput driver : 24.1
[ 2.946]X.Org Server Extension : 10.0
[ 

Bug#917924: nm-tray: does not appear in SNI tray

2018-12-31 Thread Clint Adams
Package: nm-tray
Version: 0.4.2-1

I ran nm-tray, expecting something to appear in taffybar's SNI tray
area.  It did not.

% nm-tray
QSystemTrayIcon::setVisible: No Icon set


strace shows that it is trying to access various non-existent images
in /usr/share/pixmaps .



Bug#904459: modifies conffiles (health_alarm_notify.conf)

2018-12-31 Thread Daniel Baumann
Hi,

quick update on this.. it took longer than expected because I also
realized that what goes for health_alarm_notify.conf also applies to
netdata.conf (that is currently not modified/handled by debconf, but for
which I would like to add some debconf questions for the tree basic/most
common things too).

Doing this properly and in a non-crappy way (especially because
health*.conf is shell, netdata.conf is ini format) requires a bit more
work (in the long run, I hope upstream will fix it by implementing
proper conf.d support for all configuration files).

Therefore.. to get netdata into testing as soon as possible.. I'll drop
the debconf handling for now, get that into testing, and introduce it in
some time after careful testing when everything works.

Regards,
Daniel



Bug#917923: ITP: python-pytest-random-order -- pytest plugin to randomise the order of tests (Python 3)

2018-12-31 Thread Nick Morrott
Package: wnpp
Owner: Nick Morrott ,
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-pytest-random-order
  Version : 1.0.4
  Upstream Author : Jazeps Basko 
* URL : https://github.com/jbasko/pytest-random-order
* License : Expat
  Programming Lang: Python
  Description : pytest plugin to randomise the order of tests (Python 3)

pytest-random-order is a pytest plugin that randomises the order of tests.
This can be useful to detect a test that passes just because it happens to
run after an unrelated test that leaves the system in a favourable state.

The plugin allows the user to control the level of randomness they want to
introduce and to disable reordering on subsets of tests. Tests can be rerun
in a specific order by passing a seed value reported in a previous test run.

This package installs the pytest plugin for Python 3.

I plan to maintain this package in the Debian Python Modules Team.



Bug#552275: network-manager-gnome: Wifi icons not scalable for larger panel sizes

2018-12-31 Thread Josh Triplett
On Mon, Dec 31, 2018 at 09:55:53AM +0100, Eugen Dedu wrote:
> On Sat, 24 Oct 2009 17:09:07 -0700 Josh Triplett 
> wrote:
> > Package: network-manager-gnome
> > Version: 0.7.1-1
> > Severity: normal
> > 
> > I use a 48-pixel bottom panel and no top panel.  Most tray icons scale
> > to the appropriate size, but nm-applet's wifi icons remain small.  (Some
> > of nm-applet's other icons scale appropriately, making the icon change
> > size depending on the networking state.)
> 
> Hi,
> 
> Is this bug still actual?
> 
> I am not sure if this was the same bug like me, but I use awesome with a
> larger panel, and the wi-fi icon, but also Ethernet one, contained visual
> artifacts.  Since a few days (I use Debian unstable), everything is normal,
> I have not found the reason (perhaps a recent update of libpng?)

I haven't personally observed this bug in a long time, but it was a bug
with non-GNOME-3 environments, so someone with another environment would
need to check.



Bug#917922: RM: cpufrequtils [ppc64el] -- ROP; Does not work on powerpc

2018-12-31 Thread Niels Thykier
Package: ftp.debian.org
Severity: normal

In #889895, the PowerPC powers requested that cpufrequtils was no
longer built on powerpc architectures as it does not work on those
architectures.

I have uploaded a new version of cpufrequtils that no longer builds
cpufrequtils on ppc64el and kindly ask that you remove the old binaries
left in unstable on said architectures.

Thanks,
~Niels



Bug#917921: rainloop: cannot launch admin panel

2018-12-31 Thread Joseph Nahmias
Package: rainloop
Version: 1.11.1-1
Severity: important

Dear Maintainer,

I tried to follow the instructions in the README.Debian for activating
the admin panel (I changed admin_password and set allow_admin_panel =
On) but I kept getting "Authentication failed".  Only when I changed the
password back to 12345 did it work.

Help!
--Joe


-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rainloop depends on:
ii  ckeditor4.5.7+dfsg-2
ii  libphp-predis   0.8.3-1
ii  lighttpd [httpd]1.4.45-1
ii  php-curl1:7.0+49
ii  php-fpm 1:7.0+49
ii  php-json1:7.0+49
ii  php-pclzip  2.8.2-4
ii  php-seclib  1.0.5-1
ii  php-xml 1:7.0+49
ii  php7.0-curl [php-curl]  7.0.33-0+deb9u1
ii  php7.0-fpm [php-fpm]7.0.33-0+deb9u1
ii  php7.0-json [php-json]  7.0.33-0+deb9u1
ii  php7.0-xml [php-xml]7.0.33-0+deb9u1

rainloop recommends no packages.

Versions of packages rainloop suggests:
pn  php5-sqlite | php5-mysql | php5-pgsql  

-- Configuration Files:
/etc/rainloop/application.ini changed [not included]

-- no debconf information



Bug#917752: lintian: FTBFS: tests failed

2018-12-31 Thread Felix Lechner
This bug is fixed. It can be marked as pending when the merge requests
for the two blocking bugs are accepted.



Bug#913717: quaternion: please package new upstream release 0.0.9.3

2018-12-31 Thread Jonas Smedegaard
Quoting Hubert Chathi (2018-12-31 18:15:08)
> On Wed, 14 Nov 2018 11:05:00 -0500, Hubert Chathi  said:
> 
> > In this case, I'm planning on splitting out libqmatrixclient into its
> > own package, rather than bundling it with quaternion, as it is now
> > being used by at least one other Matrix client (Spectral), which we
> > may want to package as well.
> 
> I've uploaded libqmatrixclient.  Once it clears NEW, I'll upload the new
> quaternion.

Great!

As you no doubt noticed, I didn't find time to do that myself.  But I am 
still interested in helping out here, so feel free to make me aware if 
something specific is pending.

NB! An expertise of mine is copyright and licensing examinations... :-)


 - 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#913930: Confirmed for sbuild only

2018-12-31 Thread Felix Lechner
Hi Harlan!

On Thu, Dec 27, 2018 at 9:09 PM Harlan Lieberman-Berg
 wrote:
>
> Just as one more datapoint for you, I see the same thing with
> certbot-dns-ovh with lintian 2.5.118 and sbuild 0.77.1-2.

Thank you for writing! Your package builds much faster than lxc. The
problem was fixed in

https://salsa.debian.org/lintian/lintian/merge_requests/114

Kind regards
Felix Lechner



Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

2018-12-31 Thread James McCoy
On Sun, Dec 30, 2018 at 09:30:34PM -0500, James McCoy wrote:
> Dropping debhelper and related bug, since this is just about libtermkey.
> 
> On Sun, Dec 30, 2018 at 08:22:00PM +, Niels Thykier wrote:
> > Anyhow, on to the details I have found:
> > 
> >  * Only test case 05flags.t fails and only if stdin is a *readable*
> >non-tty (e.g. /dev/null, an empty file or a non-empty file)
> > 
> >  […]
> > 
> >  * If the TERM is set to "dump", the test hangs.
> 
> Both of these issues have come up before in #809162.

Sorry, that should be #809192.

> At the time, I
> sent a patch to libtermkey's upstream to avoid the crash and then forgot
> to follow up on it.
> 
> I've sent a prod and will try to keep on top of it better this time. :)

He's looking into both issues (libtermkey NULL pointer crash and
libterm-termkey-perl's 05flags.t hang) now.  They're primarily test
issues, since it should be expected that normal use of these libraries
would have a valid TERM in the environment.

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



Bug#916392: please provide a column marker mechanism

2018-12-31 Thread Benno Schulenberg

Please try the attached patch.

Use --edge= to show a colored bar at the desired column.

Benno
From 119491bbdedf2c727135e5e331f0714d94644351 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg 
Date: Mon, 17 Dec 2018 19:57:30 +0100
Subject: [PATCH] new feature: add option --edgecolumn that shows a vertical
 guiding bar
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Option -e (--edgecolumn) takes a column number as argument and then
shows a vertical, colored bar over the entire height of the buffer,
to help the user control the width of the text when the terminal is
wider than this desired width.

[The color needs to become configurable, and would by default just
change the background color, not the foreground color.  But that is
something for a later patch.  It also needs to add an rcfile option
and documentation, of course.  Suggestions for a better name for the
option are welcome.]

This fulfills https://bugs.debian.org/916392.
Requested-by: Arturo Borrero González 
And fulfills https://savannah.gnu.org/bugs/?55315.
Requested-by: Bryan Christ 
---
 src/global.c |  2 ++
 src/nano.c   | 16 ++--
 src/proto.h  |  1 +
 src/winio.c  |  9 +
 4 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/src/global.c b/src/global.c
index 0368132f..baef8fa9 100644
--- a/src/global.c
+++ b/src/global.c
@@ -111,6 +111,8 @@ int editwincols = -1;
 		/* The number of usable columns in the edit window: COLS - margin. */
 int margin = 0;
 		/* The amount of space reserved at the left for line numbers. */
+ssize_t edge_col = 0;
+		/* The column at which a vertical bar of color will be drawn. */
 
 filestruct *cutbuffer = NULL;
 		/* The buffer where we store cut text. */
diff --git a/src/nano.c b/src/nano.c
index 263045bc..db3371b6 100644
--- a/src/nano.c
+++ b/src/nano.c
@@ -851,6 +851,10 @@ void usage(void)
 	print_opt("-c", "--constantshow", N_("Constantly show cursor position"));
 	print_opt("-d", "--rebinddelete",
 	N_("Fix Backspace/Delete confusion problem"));
+#ifndef NANO_TINY
+	print_opt("-e ", "--edgecolumn=",
+	N_("Show a guiding bar at this column"));
+#endif
 #ifdef ENABLE_BROWSER
 	if (!ISSET(RESTRICTED))
 		print_opt("-g", "--showcursor", N_("Show cursor in file browser & help text"));
@@ -2022,6 +2026,7 @@ int main(int argc, char **argv)
 		{"wordchars", 1, NULL, 'X'},
 		{"zap", 0, NULL, 'Z'},
 		{"atblanks", 0, NULL, 'a'},
+		{"edgecolumn", 0, NULL, 'e'},
 		{"autoindent", 0, NULL, 'i'},
 		{"cutfromcursor", 0, NULL, 'k'},
 		{"unix", 0, NULL, 'u'},
@@ -2084,7 +2089,7 @@ int main(int argc, char **argv)
 
 	while ((optchr =
 		getopt_long(argc, argv,
-"ABC:DEFGHIKLMNOPQ:RST:UVWX:Y:Zabcdefghijklmno:pqr:s:tuvwxyz$",
+"ABC:DEFGHIKLMNOPQ:RST:UVWX:Y:Zabcde:fghijklmno:pqr:s:tuvwxyz$",
 long_options, NULL)) != -1) {
 		switch (optchr) {
 #ifndef NANO_TINY
@@ -2203,6 +2208,14 @@ int main(int argc, char **argv)
 			case 'd':
 SET(REBIND_DELETE);
 break;
+			case 'e':
+if (!parse_num(optarg, _col) || edge_col <= 0) {
+die("here");
+	fprintf(stderr, _("Requested edge column \"%s\" is invalid"), optarg);
+	fprintf(stderr, "\n");
+	exit(1);
+}
+break;
 			case 'g':
 SET(SHOW_CURSOR);
 break;
@@ -2294,7 +2307,6 @@ int main(int argc, char **argv)
 break;
 #endif
 			case 'b':  /* Pico compatibility flags. */
-			case 'e':
 			case 'f':
 			case 'j':
 			case 'q':
diff --git a/src/proto.h b/src/proto.h
index 65890134..09e7464a 100644
--- a/src/proto.h
+++ b/src/proto.h
@@ -88,6 +88,7 @@ extern WINDOW *bottomwin;
 extern int editwinrows;
 extern int editwincols;
 extern int margin;
+extern ssize_t edge_col;
 
 extern filestruct *cutbuffer;
 extern filestruct *cutbottom;
diff --git a/src/winio.c b/src/winio.c
index e2042d9e..18f91254 100644
--- a/src/winio.c
+++ b/src/winio.c
@@ -2677,6 +2677,15 @@ void edit_draw(filestruct *fileptr, const char *converted,
 	}
 #endif /* ENABLE_COLOR */
 
+	if (edge_col > 0) {
+		const char *text = converted +  actual_x(converted, edge_col);;
+		const char *edge_char = (*text == '\0') ? " " : text;
+
+		wattron(edit, interface_color_pair[ERROR_MESSAGE]);
+		mvwaddnstr(edit, row, margin + edge_col, edge_char, 1);
+		wattroff(edit, interface_color_pair[ERROR_MESSAGE]);
+	}
+
 #ifndef NANO_TINY
 	/* If the mark is on, and fileptr is at least partially selected, we
 	 * need to paint it. */
-- 
2.19.2



Bug#913717: quaternion: please package new upstream release 0.0.9.3

2018-12-31 Thread Hubert Chathi
On Wed, 14 Nov 2018 11:05:00 -0500, Hubert Chathi  said:

> In this case, I'm planning on splitting out libqmatrixclient into its
> own package, rather than bundling it with quaternion, as it is now
> being used by at least one other Matrix client (Spectral), which we
> may want to package as well.

I've uploaded libqmatrixclient.  Once it clears NEW, I'll upload the new
quaternion.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368



Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

2018-12-31 Thread Alexander Meyer
* Thomas Dickey  [2018-12-31 00:51]:

> On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> ...
>> This is the behaviour I get across xterm versions:
>> (everything with libfontconfig1 2.13.1-2)
>> 
>> fonts.conf enabled:
>> 337: works
>> 338: segfault
>> 340: segfault
>> 341: segfault
> 
> Can you make a backtrace for #341, please?

Here it is:


Reading symbols from /usr/bin/xterm...Reading symbols from 
/usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556f2430, p_pat=0x559dea90, 
kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0  0x77d662d1 in FcConfigEvaluate (p=0x556f2430, 
p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i = 
1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, c 
= 0x556f1ad0, f = 0x556f1ad0, 
l = 0x556f1ad0, r = 0x556f1ad0}}
vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c 
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c 
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle = 
vre = 
m = 
str = 
op = 
buf1 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , "[\000\000\000w", '\000' , 
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
 '\000' , "\260\377\377\377\377\377\377\377"...}}
#1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430, 
p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont, 
e=e@entry=0x55681218) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx = 
1.4821969375237396e-323, yy = 1}
xx = 
yy = 
xy = 
yx = 
v = {type = FcTypeMatrix, u = {s = 0x3 , i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, f = 
0x3, l = 0x3, r = 0x3}}
vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", i 
= 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 0x556f24b0, 
c = 0x556f24b0, f = 0x556f24b0, 
l = 0x556f24b0, r = 0x556f24b0}}
vr = {type = FcTypeString, u = {s = 0x77d660a4 
 
"\205\300\017\224\300\017\266\300\351\267\375\377\377L\211\346H\211\327\350\364=",
 i = -136945500, b = -136945500, 
d = 6.9533490418283141e-310, m = 0x77d660a4 
, c = 0x77d660a4 , f = 
0x77d660a4 , 
l = 0x77d660a4 , r = 0x77d660a4 
}}
vle = 
vre = 
m = 
str = 
op = FcOpMatrix
buf1 = {u = {d = 4.6355706048940074e-310, i = 1432998448, l = 
93824993579568, 
c = 
"0\322iUUU\000\000\002\000\000\000\000\000\000\000\060\026jUUU\000\000\354c\326\367\377\177\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\003",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000UU\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , 
"\f\341\327\367\377\177\000\000\000\000\000\000\257\060\000\000\000\240\316\365\301\035?\376\003\000\000\000\000\000\000\000\256\340\327\367\377\177\000\000\200\326\377\377\264\060\000\000\000"...}}
buf2 = {u = {d = 4.6355706320533889e-310, i = 1433548160, l = 
93824994129280, 
c = 
"\200\065rUUU\000\000\270\220B\365\377\177\000\000\000\000\000\000\000\000\000\000\362H\327\367\377\177\000\000
 ", '\000' , 

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

2018-12-31 Thread Alexander Meyer
* Thomas Dickey  [2018-12-30 23:14]:

> On Sun, Dec 30, 2018 at 10:15:53PM +0100, Sven Joachim wrote:
>> On 2018-12-30 18:26 +0100, Alexander Meyer wrote:
>>> So the segfault only happens with that fonts.conf.
>> 
>> Thanks, that explains why others did not see it - and possibly also why
>> I could still reproduce #916349 in xterm 340, as I have my own
>> fonts.conf, albeit a much shorter and simpler one than yours.
>> 
>> Alas, with your file (saved as /tmp/fonts.conf) xterm does not even start
>> here, although I have fonts-noto-mono and fonts-noto-color-emoji
>> installed:
> 
> If xterm sees the latter, it will not start.  That's a problem that can
> only be solved by modifying Xft.  Not xterm.
> 
> But the short term goal is to get xterm working as well as feasible with
> Xft before moving on to see what can be done to make Xft handle the
> color bitmap fonts.
> 
> I'm looking for details on how to reproduce the segmentation violation
> which was reported.
>  
>> ,
>> | $ FONTCONFIG_FILE=/tmp/foo/fonts.conf xterm -fa 'Noto Mono'  
> 
> Back up a step: with that fonts.conf, I get no result for
>   fc-match 'Noto Mono'
> 
> while without it, I do get a match.  A quick look at strace tells me
> that setting FONTCONFIG_FILE eliminates a lot of the normal configuration
> information, and probably isn't what you want to do in reproducing the
> problem.

For the record: I disabled/enabled my fonts.conf by moving it out of
~/.config/fontconfig/ and then back inside. I did not set FONTCONFIG_FILE.

Also, as described in my original report, the segfault is not limited to
"Noto Mono" but seems to happen with any other font, too. (I've randomly
tried a few from my fc-list.)

>> | xterm: cannot match normal font "Noto Mono"
>> | xterm: Selected font has no non-zero height for ISO-8859-1 encoding
> 
> ...and because there's no match, for _this_ case I get the same failure.
> 
> However, that's not a bug (in xterm), but a problem with configuration.
> 
>> So I am a bit at a loss here.  And I am definitely not a an expert on
>> fontconfig (or fonts in general) either.
> 
> I'd like to see the XFT_DEBUG information from the known broken scenario.
> If it tells me that Xft is still loading the color-noto font, there's
> probably nothing that I can do to address that in xterm.

Please find attached the gzipped output of

$ XFT_DEBUG=1023 xterm -fa 'Noto Mono'

with xterm 341. All output happens directly after startup, there's no
output after issuing the command that displays the character that causes
the segfault.

Best
Alex


xterm-341-XFT_DEBUG_1023.log.gz
Description: application/gzip


Bug#917874: [pkg-apparmor] Bug#917874: /etc/init.d/apparmor: 60: shift: can't shift that many

2018-12-31 Thread Christian Boltz
Hello,

Am Montag, 31. Dezember 2018, 13:04:59 CET schrieb Jakub Wilk:
> * Christian Boltz , 2018-12-31, 12:22:
> >>The init script is broken. The start action fails with:
> >>   /etc/init.d/apparmor: 60: shift: can't shift that many
> >
> >This looks like a regression from upstream commit
> >0d5ab43d592245d011b2614e6e20fc7cb851c53c which got backported into
> >the Debian package.
> >
> >
> >The fix is most likely (untested, because I don't see this error on
> >openSUSE):
> I guess it's a bash vs dash thing:
> 
>$ bash -c 'shift; echo $?'
>1
> 
>$ dash -c 'shift; echo $?'
>dash: 1: shift: can't shift that many
> 
> I have /bin/sh pointing to dash (which is the Debian default).

Indeed, that could explain it - openSUSE defaults to bash for /bin/sh,
so it fails silently (and $? gets ignored).

> >-   if ! is_apparmor_present ; then
> >+   if ! is_apparmor_present apparmor ; then
> 
> Now I get:
> 
>Starting AppArmor - failed, To enable AppArmor, ensure your kernel
> is configured with CONFIG_SECURITY_APPARMOR=y then add
> 'security=apparmor apparmor=1' to the kernel command line
> 
> It looks like is_apparmor_present() always fails?

Right :-(

(As a sidenote - I wonder why I don't see this failure on openSUSE + 
latest rc.apparmor.functions.  Intrigeri, do you have an idea what 
Debian is doing differently? If in doubt, a   sh -x   trace might be
interesting to see. A wild guess is that the
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
test in is_apparmor_loaded() might fail for whatever reason so the 
"return" shortcut that avoids calling is_apparmor_present() doesn't get
taken.)


Back to the bug - the failure is caused by this test:

[ $? -ne 0 -a -d /sys/module/apparmor ]

Note that the check uses   -ne   so it expects that $? != 0.
However, the while loop always ends with $? = 0, so the test always 
fails.


I'll have to do a little history lesson to explain what happened ;-)

The old version of the function was:

# Test if the apparmor "module" is present.
is_apparmor_present() {
local modules=$1
shift

while [ $# -gt 0 ] ; do
modules="$modules|$1"
shift
done

# check for subdomainfs version of module
grep -qE "^($modules)[[:space:]]" /proc/modules

[ $? -ne 0 -a -d /sys/module/apparmor ]

return $?
}

The function was called in two ways:
is_apparmor_present apparmor
is_apparmor_present apparmor subdomain
so basically /proc/modules was grepped for "apparmor" and "subdomain".
Since AppArmor gets built into the kernel (not as a module) since many 
years, that grep never found anything in /proc/modules and returned 
with $? = 1. (We could also have called "false" instead of grep - same 
result with less CPU cycles ;-)

The cleanup ("because AppArmor wasn't a kernel module since many years") 
removed that seemingly superfluous and pointless grep.

However, removing the grep means that $? no longer gets set to 1 (the 
while loop ends up with $? = 0), and that means that the function always 
fails.


That all said - can you please test with this patch?

--- a/parser/rc.apparmor.functions
+++ b/parser/rc.apparmor.functions
@@ -61,15 +62,9 @@ STATUS=0
 
 # Test if the apparmor "module" is present.
 is_apparmor_present() {
-   local modules=$1
-   shift
+   # TODO: change callers - handing over a parameter is no longer needed
 
-   while [ $# -gt 0 ] ; do
-   modules="$modules|$1"
-   shift
-   done
-
-   [ $? -ne 0 -a -d /sys/module/apparmor ]
+   [ -d /sys/module/apparmor ]
 
return $?
 }


The function should now look like this:

is_apparmor_present() {
# TODO: change callers - handing over a parameter is no longer needed

[ -d /sys/module/apparmor ]

return $?
}

> >the only code that still actually does something there is
> >
> >[ -d /sys/module/apparmor ]
> 
> With this one-line implementation of is_apparmor_present(), the script
> seems to work, but I get warnings about missing functions:
> 
>/etc/init.d/apparmor: 209: /etc/init.d/apparmor:
> aa_log_action_start: not found /etc/init.d/apparmor: 221:
> /etc/init.d/apparmor: aa_log_action_end: not found

That could be a Debian-specific issue - I'll let intrigeri handle this 
part ;-)  (a quick look indicates that these messages are "only" 
annoying, but shouldn't break anything)


Regards,

Christian Boltz
-- 
Honestly - I ignore every thread Basil or Linda take part in. I wonder
if we can somehow automate that. Perhaps a opensuse-factory-sane list
that is feed by opensuse-factory posts but automatically filters such
threads and posts? [Stephan Kulow in opensuse-factory]


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


Bug#917920: fakechroot: fails to find libsystemd-shared-240.so when installin systemd

2018-12-31 Thread Johannes 'josch' Schauer
Package: fakechroot
Version: 2.19-3
Severity: normal

Hi,

when installing systemd under fakechroot one currently gets the
following error during package configuration.

Setting up systemd (240-2) ...
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → 
/lib/systemd/system/getty@.service.
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → 
/lib/systemd/system/remote-fs.target.
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → 
/lib/systemd/system/systemd-timesyncd.service.
Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.
systemd-machine-id-setup: error while loading shared libraries: 
libsystemd-shared-240.so: cannot open shared object file: No such file or 
directory
dpkg: error processing package systemd (--configure):
 installed systemd package post-installation script subprocess returned error 
exit status 127
Setting up dmsetup (2:1.02.155-1) ...
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

A workaround is to add "/lib/systemd" to LD_LIBRARY_PATH. But maybe
there is a better solution. Anyways, this should work out-of-the-box.

Thanks!

cheers, josch


Bug#917919: RM: pyorbit -- ROM, RoQA; unmaintained library

2018-12-31 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: pyor...@packages.debian.org
Affects: src:pyorbit
Tags: moreinfo
Control: block -1 by 917918

pyorbit has been unmaintained for years. Now that gnome-python is
being removed, it should be removed too.

pyorbit was removed from Testing a year ago:
https://bugs.debian.org/884988

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#917909: [text-based installer] right-to-left writing direction broken

2018-12-31 Thread Samuel Thibault
Control: reassign -1 fribidi
Control: tags -1 + patch

Samuel Thibault, le lun. 31 déc. 2018 17:20:42 +0100, a ecrit:
> Holger Wansing, le lun. 31 déc. 2018 16:15:12 +0100, a ecrit:
> > While investigating an old bugreport regarding Hebrew, I found that RTL 
> > writing
> > direction is completely broken in the text-based installer
> > (writing direction seems left-to-right and text is aligned to the left).
> > 
> > That's also the case in Stretch, while it was ok in Jessie installer!
> 
> Indeed, I can confirm this.  I tried to copy the Jessie libnewt.so.0.52
> into a Stretch image, and it fixes the issue, so I believe the
> regression is within the newt package, thus somewhere between newt
> 0.52.17-1 and 0.52.19-1.

Ah, it's 98fa157c758d ('bidi.patch: Look for libfribidi in multi-arch
directory.'). In fribidi's udeb libfribidi.so.0 is in /lib, not
/usr/lib/$MACH, is there really a reason for doing so?  I'd say we
should move it there, i.e. the attached patch? (which I could check
as fixing the issue in the textual installer, without breaking the
graphical installer). And we can probably backport it to Stretch.

Samuel
diff --git a/debian/libfribidi0-udeb.install b/debian/libfribidi0-udeb.install
index 6b97e71..c3f6cb1 100644
--- a/debian/libfribidi0-udeb.install
+++ b/debian/libfribidi0-udeb.install
@@ -1 +1 @@
-usr/lib/*/libfribidi.so.* lib
+usr/lib/*/libfribidi.so.*


Bug#917918: RM: gnome-python -- ROM, RoQA; unmaintained depends on libgnome

2018-12-31 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: gnome-pyt...@packages.debian.org
Affects: src:gnome-python
Tags: moreinfo
Control: block -1 by 790584 917210

gnome-python has been unmaintained for years and is one of the blockers for
removing the other unmaintained libgnome libraries.

gnome-pythonwas removed from Testing a year ago:
https://bugs.debian.org/884986

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#917863: webext-privacy-badger: Loaded but inoperable

2018-12-31 Thread Markus Koschany
Hi Bruno,

Am 31.12.18 um 06:54 schrieb Bruno Kleinert:
> Package: webext-privacy-badger
> Version: 2018.12.17-1
> Severity: important
> 
> Hi,
> 
> in Firefox ESR (currently 60.4.0esr-1) the pluget appears as if it is
> successfully loaded, but when browsing the web it seems to do nothing.
> I.e., it doesn't show any trackers on any website where I know it will
> find some, nor does it show its own version information when clicked on
> the badger symbol in the button bar.

I have just tested privacybadger with firefox-esr in Buster but I can't
reproduce this behavior. When I go to youtube.com two trackers are
detected and successfully blocked.


> When I build and install version 2018.12.5-2 from 
> https://salsa.debian.org/webext-team/privacybadger.git, it works as
> expected: It shows trackers it detects and displays its version
> information.
> 
> However, in Firefox (non-ESR, currently 64.0-1) privacy badger works as
> expected, so it seems related only to Firefox ESR.
> 
> Cheers - Bruno

That is weird. Could you try again with 2018.12.17 after you have
cleared your Firefox cache in ~/.cache/mozilla. Is this also
reproducible when you create a complete new Firefox profile?

Regards,

Markus




signature.asc
Description: OpenPGP digital signature


Bug#915353: vdr-plugin-skinenigmang: diff for NMU version 0.1.2+git20180128-2.1

2018-12-31 Thread Adrian Bunk
Control: tags 915353 + pending

Dear maintainer,

I've prepared an NMU for vdr-plugin-skinenigmang (versioned as 
0.1.2+git20180128-2.1)
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog
--- vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog	2018-04-15 20:43:46.0 +0300
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/debian/changelog	2018-12-31 18:17:16.0 +0200
@@ -1,3 +1,10 @@
+vdr-plugin-skinenigmang (0.1.2+git20180128-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS without freetype-config. (Closes: #915353)
+
+ -- Adrian Bunk   Mon, 31 Dec 2018 18:17:16 +0200
+
 vdr-plugin-skinenigmang (0.1.2+git20180128-2) unstable; urgency=medium
 
   * VCS moved to salsa.debian.org
diff -Nru vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config
--- vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config	1970-01-01 02:00:00.0 +0200
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/no-freetype-config	2018-12-31 18:17:16.0 +0200
@@ -0,0 +1,18 @@
+Description: freetype-config was removed in Debian, switch to pkg-config
+Author: Adrian Bunk 
+
+--- vdr-plugin-skinenigmang-0.1.2+git20180128.orig/Makefile
 vdr-plugin-skinenigmang-0.1.2+git20180128/Makefile
+@@ -138,9 +138,9 @@ INCLUDES += $(shell pkg-config --cflags
+ endif
+ endif
+ 
+-ifneq ($(shell which freetype-config),)
+-	INCLUDES += $(shell freetype-config --cflags)
+-	LIBS += $(shell freetype-config --libs)
++ifneq ($(shell which pkg-config),)
++	INCLUDES += $(shell pkg-config --cflags freetype2)
++	LIBS += $(shell pkg-config --libs freetype2)
+ else
+ 	INCLUDES += -I/usr/include/freetype -I/usr/local/include/freetype
+ 	LIBS += -lfreetype
diff -Nru vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series
--- vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series	2018-04-15 20:43:46.0 +0300
+++ vdr-plugin-skinenigmang-0.1.2+git20180128/debian/patches/series	2018-12-31 18:17:16.0 +0200
@@ -1,2 +1,3 @@
 fix-imagemagick-path.patch
 vdr-plugin-skinenigma_min_max_from_stl.patch
+no-freetype-config


Bug#917909: [text-based installer] right-to-left writing direction broken

2018-12-31 Thread Samuel Thibault
Control: reassign -1 newt
Control: fixed -1 0.52.17-1
Control: found -1 0.52.19-1

Hello,

Holger Wansing, le lun. 31 déc. 2018 16:15:12 +0100, a ecrit:
> While investigating an old bugreport regarding Hebrew, I found that RTL 
> writing
> direction is completely broken in the text-based installer
> (writing direction seems left-to-right and text is aligned to the left).
> 
> That's also the case in Stretch, while it was ok in Jessie installer!

Indeed, I can confirm this.  I tried to copy the Jessie libnewt.so.0.52
into a Stretch image, and it fixes the issue, so I believe the
regression is within the newt package, thus somewhere between newt
0.52.17-1 and 0.52.19-1.

Samuel



Bug#917915: Updating the phpunit Uploaders list

2018-12-31 Thread Mattia Rizzolo
Source: phpunit
Version: 7.5.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the phpunit package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#917910: plasma-desktop: separate binary package for xembedsniproxy

2018-12-31 Thread Clint Adams
On Mon, Dec 31, 2018 at 04:51:21PM +0100, Pino Toscano wrote:
> > Please split xembedsniproxy out into its own binary package.  I
> > don't want the entirety of plasma-desktop and all its dependencies
> > just for this single utility.
> 
> What is the use case for it?

taffybar dropped gtk-traymanager support in favor of SNI.  I want
nm-applet to appear in my taffybar tray so I need to use
xembedsniproxy.  This doesn't work very well, so if there is a better
way of accomplishing this, I'm all ears.



Bug#917916: Updating the nusoap Uploaders list

2018-12-31 Thread Mattia Rizzolo
Source: nusoap
Version: 0.9.5-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the nusoap package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#917913: Updating the rdflib Uploaders list

2018-12-31 Thread Mattia Rizzolo
Source: rdflib
Version: 4.2.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the rdflib package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#917914: Updating the planet-venus Uploaders list

2018-12-31 Thread Mattia Rizzolo
Source: planet-venus
Version: 0~git9de2109-4.2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the planet-venus package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#917912: Updating the sparql-wrapper-python Uploaders list

2018-12-31 Thread Mattia Rizzolo
Source: sparql-wrapper-python
Version: 1.7.6-2.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Olivier Berger  has retired, so can't work on
the sparql-wrapper-python package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to

2018-12-31 Thread Tormod Volden
Hi,
Thanks for your bug report. I can confirm this issue, for instance by
running glitchpeg standalone:

usage: xscreensaver-getimage-file [--verbose] directory-or-feed-url

   Prints the name of a randomly-selected image file.  The directory
   is searched recursively.  Images smaller than 255x255 are excluded.

   The directory may also be the URL of an RSS/Atom feed.  Enclosed
   images will be downloaded and cached locally.

glitchpeg: unable to read


Best regards,
Tormod



On Mon, Nov 19, 2018 at 3:45 PM Francesco Potortì wrote:
>
> Even though I have this in my ~/.xscreensaver:
>
> grabDesktopImages:  True
> grabVideoFrames:False
> chooseRandomImages: False
> imageDirectory:
>
> xscreensaver gives an error saying that xscreensaver-getimage-file
> cannot find the image directory.
>
> P.S. is this package still maintained?  I see lots of very old bugs, one
> from 2001...
>



Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

2018-12-31 Thread Stefano Zacchiroli
tag 917532 + pending
thanks

Fava is now in NEW.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature


Bug#917909: Fw: Bug#917909: [text-based installer] right-to-left writing direction broken

2018-12-31 Thread Holger Wansing
Forwarding this to translators of relevant languages:


Hi all,

I would like to get your attention on this bugreport for the debian-installer.
It looks to me, as if RTL writing direction is no longer correct in the 
text-based installer.

But as I am not a mother-tongue speaker of the affected languages, I would like
to have some opinion/acknoledgement from you regarding this.

The bugreport contains some screenshots, where you can see the text-based an
the graphical installer - side-by-side - for all those languages.
IMO the graphical installer looks good, while the text-based one - with the
blue background - is not correct.


Note: the screenshot were created with the buster-alpha4 netinst ISO image.



Many thanks
Holger







Date: Mon, 31 Dec 2018 16:15:12 +0100
From: Holger Wansing 
To: Debian Bug Tracking System 
Subject: Bug#917909: [text-based installer] right-to-left writing direction 
broken


Package: debian-installer
Severity: important


While investigating an old bugreport regarding Hebrew, I found that RTL writing
direction is completely broken in the text-based installer
(writing direction seems left-to-right and text is aligned to the left).

That's also the case in Stretch, while it was ok in Jessie installer!

I will sent some screenshots to the bug later, to document it.


As we are near the freeze for Buster, it would probably be the best way to 
work around this, if we disable the RTL langugages completely in the text-based 
installer (since they are also supported there and it seems ok in the 
graphical installer) ?

This affects:   Arabic
Hebrew
Persian
Uyghur



I will point relevant people to this bug, to get opinions from mother-tongue 
speakers | readers ...



Holger



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



Bug#917910: plasma-desktop: separate binary package for xembedsniproxy

2018-12-31 Thread Pino Toscano
severity 917910 wishlist
thanks

Hi,

In data lunedì 31 dicembre 2018 16:19:34 CET, Clint Adams ha scritto:
> Source: plasma-desktop
> Version: 4:5.14.3-1
> 
> Please split xembedsniproxy out into its own binary package.  I
> don't want the entirety of plasma-desktop and all its dependencies
> just for this single utility.

What is the use case for it?

-- 
Pino Toscano

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


Bug#917911: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018i

2018-12-31 Thread gregor herrmann
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.09-1+2018i to s-p-u. It
includes yesterday's Olson DB release 2018i as a quilt patch, which
has the following change:

São Tomé and Príncipe switches from +01 to +00 on 2019-01-01.

I'm attaching a stripped down debdiff.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlwqOexfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbluA/+MvbKGkKbTmd60KT2cAGF4ZO+Gm/c/wTvZUcQspCFHleLIoapHbJcnohq
3sGE5YXk63cDnAQIGwAsrbT0ijN2rOv8OcZsEsbpp/3SK4X3AUxkd8eufkY4fe9e
nnilU5J1z1Dow4M9jHduU/P+YKdU8/5DcscNJmsR/8jJ85hYCADqT9wUKLgSog2b
qMDOd0ky0b5Sq0hwicrO2xpBeoECQqEdHiInfuJHdY/O3FI3xwisOZbEot/r+cxt
ZrVLnhdJIVxw5KQ0HD8DMWZzD3O0oak8C5eVJzk6qMv81hkV168P8vWTfvEKOTc1
KWOXgRVZ9Ylk0oocVO58IuEnRErMck77w+H1K8lCR2EGhtS1KHYyQWoRaSLNcdKp
54/B+ioYHKPtGhFsMC2eFh4VnY2T9KMjetuFkGaJMXWxE2k7hVQRqejOpK1TwnpH
qW0Dob7r87XAEX0srqvlm028tO7sPyLO2Xr9OvjWS3jOkLKXY6jP/tyOLGQN4fMc
hF8oJ6okMS1HeRTuKxDsaTs0uwyDbd/wSHTyUpiXJXGhUOvrGHptUitFEtyL3pPm
sCmft60HiuNW2saiWG+K+ITX+ipp3ZsChG0iPUa1lFh7/XPd3sFg21iiRXpNnjX/
L1V6bvq2GfAsArMb9V3Y0uOjWGn2LXd+yozmiafIeQMhGyAKNSo=
=wu+T
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.09/debian/changelog 
libdatetime-timezone-perl-2.09/debian/changelog
--- libdatetime-timezone-perl-2.09/debian/changelog 2018-12-30 
17:40:45.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/changelog 2018-12-31 
16:38:55.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.09-1+2018i) stretch; urgency=medium
+
+  * Update to Olson database version 2018i.
+This update contains contemporary changes for São Tomé and Príncipe.
+
+ -- gregor herrmann   Mon, 31 Dec 2018 16:38:55 +0100
+
 libdatetime-timezone-perl (1:2.09-1+2018h) stretch; urgency=medium
 
   * Update to Olson database version 2018h.
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/olson-2018i 
libdatetime-timezone-perl-2.09/debian/patches/olson-2018i
--- libdatetime-timezone-perl-2.09/debian/patches/olson-2018i   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/olson-2018i   2018-12-31 
16:38:55.0 +0100
@@ -0,0 +1,9712 @@
+Description: update to olson db 2018i
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2018-12-31
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2018h
++# Generated from debian/tzdata/africa.  Olson data version 2018i
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2018h'}
++sub olson_version {'2018i'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Africa/Sao_Tome.pm
 b/lib/DateTime/TimeZone/Africa/Sao_Tome.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2018h
++# Generated from debian/tzdata/africa.  Olson data version 2018i
+ #
+ # Do not edit this file directly.
+ #
+@@ -52,16 +52,25 @@
+ ],
+ [
+ 63650451600, #utc_start 2018-01-01 01:00:00 (Mon)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63681987600, #  utc_end 2019-01-01 01:00:00 (Tue)
+ 63650455200, #  local_start 2018-01-01 02:00:00 (Mon)
+-DateTime::TimeZone::INFINITY, #local_end
++63681991200, #local_end 2019-01-01 02:00:00 (Tue)
+ 3600,
+ 0,
+ 'WAT',
+ ],
++[
++63681987600, #utc_start 2019-01-01 01:00:00 (Tue)
++DateTime::TimeZone::INFINITY, #  utc_end
++63681987600, #  local_start 2019-01-01 01:00:00 (Tue)
++DateTime::TimeZone::INFINITY, #local_end
++0,
++0,
++'GMT',
++],
+ ];
+ 
+-sub olson_version {'2018h'}
++sub olson_version {'2018i'}
+ 
+ sub has_dst_changes {0}
+ 
diff -Nru libdatetime-timezone-perl-2.09/debian/patches/series 
libdatetime-timezone-perl-2.09/debian/patches/series
--- libdatetime-timezone-perl-2.09/debian/patches/series2018-12-30 
17:40:45.0 +0100
+++ libdatetime-timezone-perl-2.09/debian/patches/series2018-12-31 
16:38:55.0 +0100
@@ -7,3 +7,4 @@
 olson-2018f
 olson-2018g
 olson-2018h
+olson-2018i


Bug#917859: vim FTBFS building for armel,armhf on arm64

2018-12-31 Thread James McCoy
On Mon, Dec 31, 2018 at 04:38:10AM +, Steve McIntyre wrote:
> I've been doing a full rebuild of the Debian archive, building all
> source packages targeting armel and armhf using arm64 hardware. We are
> planning in future to move all of our 32-bit armel/armhf builds to
> using arm64 machines, so this rebuild is to identify packages that
> might have problems with this configuration.

Thanks for doing this work!

> Test results:
> 
> 
> From test_search.vim:
> Found errors in Test_incsearch_substitute_dump():
> Run 1:
> function RunTheTest[40]..Test_incsearch_substitute_dump[40]..VerifyScreenDump 
> line 18: See dump file difference: call 
> term_dumpdiff("Test_incsearch_substitute_03.dump.failed", 
> "dumps/Test_incsearch_substitute_03.dump")
> Run 2:
> function RunTheTest[40]..Test_incsearch_substitute_dump[40]..VerifyScreenDump 
> line 18: See dump file difference: call 
> term_dumpdiff("Test_incsearch_substitute_03.dump.failed", 
> "dumps/Test_incsearch_substitute_03.dump")
> Flaky test failed too often, giving up
> 
> From test_alot.vim:
> Found errors in Test_compiler():
> function RunTheTest[40]..Test_compiler line 18: command did not fail: clist
> function RunTheTest[40]..Test_compiler line 24: Pattern '\n 1 Xfoo.pl:3: 
> Global symbol "$foo" requires explicit package name' does not match '\n11 
> Xfoo.pl:3: Global symbol "$foo" requires explicit package name (did you 
> forget to declare "my $foo"?)'
> TEST FAILURE
> make[2]: *** [Makefile:48: report] Error 1
> make[2]: Leaving directory '/<>/src/vim-basic/testdir'
> make[1]: *** [Makefile:2121: scripttests] Error 2
> make[1]: Leaving directory '/<>/src/vim-basic'
> make: *** [debian/rules:261: build-stamp-vim-basic] Error 2
> rm configure-stamp-vim-basic
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> ...
> 
> I've no idea why this one particular test is failing :-(

The VerifyScreenDump ones are known to be flaky, but it would still help
if they actually showed the problem when they were marked as failed. :(
I should talk to upstream about that.

The "Test_compiler line 24" one is odd.  All that test does is create a
file foo.pl

#!/usr/bin/perl -w
use strict;
$foo=1;

and then run "perl -c foo.pl".  It expects there to be 1 line of output,
stating that "$foo" isn't declared.  However, there appears to be 11
lines of output.  That should be easy to verify independently.

Is there a way for me to replicate this new environment on the
porterboxes so I can debug further?

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



Bug#915559: coreutils: Use renameat2 from glibc instead of syscall

2018-12-31 Thread Johannes Schauer
Hello again,

Quoting Johannes Schauer (2018-12-31 10:58:18)
> I'm sorry, but my attached patch was apparently not properly tested by me. :(
> 
> More work is needed to backport the patch from upstream to version 8.30 
> because
> just calling renameat2 as proposed in the patch I attached in my first message
> will just result in an infinite recursion loop. I guess I only didn't notice
> because the initial patch never worked because HAVE_RENAMEAT2 never got 
> defined
> as the following hunk was missing from it:
> 
> --- coreutils-8.30.orig/lib/config.hin
> +++ coreutils-8.30/lib/config.hin
> @@ -2069,6 +2069,9 @@
>  /* Define to 1 if you have the `renameat' function. */
>  #undef HAVE_RENAMEAT
>  
> +/* Define to 1 if you have the `renameat2' function. */
> +#undef HAVE_RENAMEAT2
> +
>  /* Define to 1 if you have the `rewinddir' function. */
>  #undef HAVE_REWINDDIR
> 
> 
> I only now started to understand how the Debian package includes the gnulib
> submodule and ends up shipping a number of autogenerated files as well.
> 
> Upstream doesn't have the problem of infinite recursion because they renamed
> renameat2 to renameatu. So one way of solving this would be to also backport
> that change.
> 
> Would you be okay with that or would you like to see another solution?
> 
> How much time do I have to present a working patch?

I think I've got it this time. Please find attached two patches. One renames
the renameat2 function to renameatu (as it was done upstream) and the other
adds support for using glibc renameat2 instead of the systemcall (and also
includes the missing hunk from lib/config.hin).

The renameatu patch is very small because the Debian package does not seem to
run the testsuite? At least it compiles fine and seems to work fine together
with my patch to fakechroot in #909612.

Sorry to not have gotten it right when I reported the bug.

Is there anything else you'd like me to do for this bug?

Thanks!

cheers, josch
From: Johannes 'josch' Schauer 
Date: Tue, 4 Dec 2018 20:57:48 +0100
X-Dgit-Generated: 8.30-1.1 2474a66055eceaf668b315d83ae7b0ae7bf9a4d5
Subject: Prefer renameat2 from glibc over syscall if available

This is necessary for fakechroot to be able to overwrite renameat2 which
is used by mv(1) from coreutils. See #909612

This patch is based on a patch by Andreas Henriksson 
which was accepted in gnulib git:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c

---

--- coreutils-8.30.orig/lib/config.hin
+++ coreutils-8.30/lib/config.hin
@@ -2069,6 +2069,9 @@
 /* Define to 1 if you have the `renameat' function. */
 #undef HAVE_RENAMEAT
 
+/* Define to 1 if you have the `renameat2' function. */
+#undef HAVE_RENAMEAT2
+
 /* Define to 1 if you have the `rewinddir' function. */
 #undef HAVE_REWINDDIR
 
--- coreutils-8.30.orig/lib/renameat2.c
+++ coreutils-8.30/lib/renameat2.c
@@ -77,7 +77,10 @@ renameat2 (int fd1, char const *src, int
   int ret_val = -1;
   int err = EINVAL;
 
-#ifdef SYS_renameat2
+#if HAVE_RENAMEAT2
+  ret_val = renameat2 (fd1, src, fd2, dst, flags);
+  err = errno;
+#elif defined SYS_renameat2
   ret_val = syscall (SYS_renameat2, fd1, src, fd2, dst, flags);
   err = errno;
 #elif defined RENAME_EXCL
--- coreutils-8.30.orig/m4/renameat.m4
+++ coreutils-8.30/m4/renameat.m4
@@ -15,7 +15,7 @@ AC_DEFUN([gl_FUNC_RENAMEAT],
   AC_REQUIRE([gl_STDIO_H_DEFAULTS])
   AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
   AC_CHECK_HEADERS([linux/fs.h])
-  AC_CHECK_FUNCS_ONCE([renameat])
+  AC_CHECK_FUNCS_ONCE([renameat renameat2])
   if test $ac_cv_func_renameat = no; then
 HAVE_RENAMEAT=0
   elif test $REPLACE_RENAME = 1; then
From: Johannes 'josch' Schauer 
Date: Mon, 31 Dec 2018 11:03:58 +0100
X-Dgit-Generated: 8.30-1.1 8209088c5a946519942aba2b13200c8d09b14c91
Subject: renameatu


---

--- coreutils-8.30.orig/lib/backupfile.c
+++ coreutils-8.30/lib/backupfile.c
@@ -353,7 +353,7 @@ backupfile_internal (char const *file, e
   base_offset = 0;
 }
   unsigned flags = backup_type == simple_backups ? 0 : RENAME_NOREPLACE;
-  if (renameat2 (AT_FDCWD, file, sdir, s + base_offset, flags) == 0)
+  if (renameatu (AT_FDCWD, file, sdir, s + base_offset, flags) == 0)
 break;
   int e = errno;
   if (e != EEXIST)
--- coreutils-8.30.orig/lib/renameat.c
+++ coreutils-8.30/lib/renameat.c
@@ -21,5 +21,5 @@
 int
 renameat (int fd1, char const *src, int fd2, char const *dst)
 {
-  return renameat2 (fd1, src, fd2, dst, 0);
+  return renameatu (fd1, src, fd2, dst, 0);
 }
--- coreutils-8.30.orig/lib/renameat2.c
+++ coreutils-8.30/lib/renameat2.c
@@ -71,7 +71,7 @@ rename_noreplace (char const *src, char
function is equivalent to renameat (FD1, SRC, FD2, DST).  */
 
 int
-renameat2 (int fd1, char const *src, int fd2, char const *dst,
+renameatu (int fd1, char const *src, int fd2, char const *dst,
unsigned int flags)
 {
   int ret_val = -1;
--- coreutils-8.30.orig/lib/renameat2.h
+++ 

Bug#915344: openfoam: diff for NMU version 4.1+dfsg1-2.3

2018-12-31 Thread Adrian Bunk
Control: tags 915344 + patch
Control: tags 915344 + pending

Dear maintainer,

I've prepared an NMU for openfoam (versioned as 4.1+dfsg1-2.3) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian

--

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

diff -Nru openfoam-4.1+dfsg1/debian/changelog openfoam-4.1+dfsg1/debian/changelog
--- openfoam-4.1+dfsg1/debian/changelog	2018-08-12 13:41:17.0 +0300
+++ openfoam-4.1+dfsg1/debian/changelog	2018-12-31 10:22:02.0 +0200
@@ -1,3 +1,11 @@
+openfoam (4.1+dfsg1-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with glibc 2.28,
+thanks to Juhani Numminen. (Closes: #915344)
+
+ -- Adrian Bunk   Mon, 31 Dec 2018 10:22:02 +0200
+
 openfoam (4.1+dfsg1-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru openfoam-4.1+dfsg1/debian/patches/90_glibc.patch openfoam-4.1+dfsg1/debian/patches/90_glibc.patch
--- openfoam-4.1+dfsg1/debian/patches/90_glibc.patch	1970-01-01 02:00:00.0 +0200
+++ openfoam-4.1+dfsg1/debian/patches/90_glibc.patch	2018-12-31 10:22:02.0 +0200
@@ -0,0 +1,24 @@
+From 3fba921563fdb4436f73ace89fe9762474907953 Mon Sep 17 00:00:00 2001
+From: Henry Weller 
+Date: Tue, 25 Jul 2017 00:03:09 +0100
+Subject: POSIX::fileStat: Avoid warning from gcc
+
+---
+ src/OSspecific/POSIX/fileStat.C | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/OSspecific/POSIX/fileStat.C b/src/OSspecific/POSIX/fileStat.C
+index 37994508c..9139a3469 100644
+--- a/src/OSspecific/POSIX/fileStat.C
 b/src/OSspecific/POSIX/fileStat.C
+@@ -29,6 +29,7 @@ License
+ 
+ #include 
+ #include 
++#include 
+ 
+ // * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //
+ 
+-- 
+2.11.0
+
diff -Nru openfoam-4.1+dfsg1/debian/patches/series openfoam-4.1+dfsg1/debian/patches/series
--- openfoam-4.1+dfsg1/debian/patches/series	2018-08-03 23:38:10.0 +0300
+++ openfoam-4.1+dfsg1/debian/patches/series	2018-12-31 10:22:02.0 +0200
@@ -6,3 +6,4 @@
 60_disable_dummy_packages.patch
 70_remove_IRIX_includes.patch
 80_gcc8.patch
+90_glibc.patch


Bug#909612: fakechroot: does not support renameat2

2018-12-31 Thread Johannes Schauer
Hi,

On Tue, 25 Sep 2018 23:05:45 +0200 Johannes 'josch' Schauer  
wrote:
> fakechroot currently doesn't support the renameat2 system call. This means
> that the 'mv' from coreutils in current Debian unstable and testing will not
> work. This in turn doesn't make fakechroot very useful for using it with
> Debian unstable and testing. Older Debian releases still work though.
> 
> I will leave the decision whether you consider the lack of 'mv' inside
> fakechroot an RC bug or not up to you.

attached patch fixes the problem.

I could NMU fakechroot with the patch. Would that be okay for you?

Thanks!

cheers, josch
--- a/config.h.in
+++ b/config.h.in
@@ -526,6 +526,9 @@
 /* Define to 1 if you have the `renameat' function. */
 #undef HAVE_RENAMEAT
 
+/* Define to 1 if you have the `renameat2' function. */
+#undef HAVE_RENAMEAT2
+
 /* Define to 1 if you have the `revoke' function. */
 #undef HAVE_REVOKE
 
--- a/configure.ac
+++ b/configure.ac
@@ -252,6 +252,7 @@ AC_CHECK_FUNCS(m4_normalize([
 removexattr
 rename
 renameat
+renameat2
 revoke
 rmdir
 scandir
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -135,6 +135,7 @@ libfakechroot_la_SOURCES = \
 removexattr.c \
 rename.c \
 renameat.c \
+renameat2.c \
 revoke.c \
 rmdir.c \
 rpl_lstat.c \
--- /dev/null
+++ b/src/renameat2.c
@@ -0,0 +1,42 @@
+/*
+libfakechroot -- fake chroot environment
+Copyright (c) 2010, 2013 Piotr Roszatycki 
+
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.
+
+This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Lesser General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA
+*/
+
+
+#include 
+
+#ifdef HAVE_RENAMEAT2
+
+#define _ATFILE_SOURCE
+#include "libfakechroot.h"
+
+
+wrapper(renameat2, int, (int olddirfd, const char * oldpath, int newdirfd, const char * newpath, unsigned int flags))
+{
+char tmp[FAKECHROOT_PATH_MAX];
+debug("renameat2(%d, \"%s\", %d, \"%s\", %d)", olddirfd, oldpath, newdirfd, newpath, flags);
+expand_chroot_path_at(olddirfd, oldpath);
+strcpy(tmp, oldpath);
+oldpath = tmp;
+expand_chroot_path_at(newdirfd, newpath);
+return nextcall(renameat2)(olddirfd, oldpath, newdirfd, newpath, flags);
+}
+
+#else
+typedef int empty_translation_unit;
+#endif


signature.asc
Description: signature


Bug#833268: task-lxde-desktop: LXDE desktop does not include a web browser

2018-12-31 Thread Holger Wansing
Control: reassign -1 lxde


Jonathan Dowland  wrote:
> If I were to try and
> summarize it as succinctly as possible, it would be
> 
>   "LXDE desktop include an icon to launch a graphical web browser,
>   but does not depend upon one."
> 
> And that's still the situation since the virtual package www-browser ≠ a
> graphical one, since it can be satisfied by w3m or links and others.

Therefore forwarding to LXDE people.

@lxde: if you want to get that solved by a change in the xlde task, let me 
know.


Regards
Holger

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



Bug#917910: plasma-desktop: separate binary package for xembedsniproxy

2018-12-31 Thread Clint Adams
Source: plasma-desktop
Version: 4:5.14.3-1

Please split xembedsniproxy out into its own binary package.  I
don't want the entirety of plasma-desktop and all its dependencies
just for this single utility.



Bug#917909: [text-based installer] right-to-left writing direction broken

2018-12-31 Thread Holger Wansing
Package: debian-installer
Severity: important


While investigating an old bugreport regarding Hebrew, I found that RTL writing
direction is completely broken in the text-based installer
(writing direction seems left-to-right and text is aligned to the left).

That's also the case in Stretch, while it was ok in Jessie installer!

I will sent some screenshots to the bug later, to document it.


As we are near the freeze for Buster, it would probably be the best way to 
work around this, if we disable the RTL langugages completely in the text-based 
installer (since they are also supported there and it seems ok in the 
graphical installer) ?

This affects:   Arabic
Hebrew
Persian
Uyghur



I will point relevant people to this bug, to get opinions from mother-tongue 
speakers | readers ...



Holger



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



Bug#838344: Acknowledgement (linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready)

2018-12-31 Thread Elmar Stellnberger
  It is now about two years ago that I have developed a patch to set 
the TMDS frequency for Radeon cards. A similar patch for Nouveau and for 
the Windows ATI driver does already exist. The patch has been proven to 
work well in the long term at least with the Radeon R5 230 and the 
Radeon HD 6570. Other people have given positive reports as well (Radeon 
HD 6970, Radeon HD 6770, see: 
https://bugs.freedesktop.org/show_bug.cgi?id=93885#c24) though not as 
extensively as John Reinhard with the HD 6570.
  Many cards do not show heat issues at all when overclocking the TMDS. 
- and even if a card did Nouveau developers have told me that it would 
hardly be possible to damage a card with this. The reason why Radeon 
developers did not want to assimilate it seems to be business interest 
as they have told me frankly. The patch is safe and has been proven 
useful (since then many people with positive experience have linked to 
my site) - so why do we not include it for Debian?




Bug#917908: RM: blktap-dkms -- RoQA; obsolete, FTBFS

2018-12-31 Thread Ben Hutchings
Package: ftp.debian.org
Severity: normal

blktap was replaced by blktap2  in
current versions of Xen.  It hasn't been possible to build a kernel
module with this package since Linux 4.12 (#874751), over a year ago.
The related userspace code (blktap package) was also broken by
glibc changes around the same time.

Ben.



Bug#874751: [Pkg-xen-devel] Bug#874751: Processed: severity of 874751 is grave

2018-12-31 Thread Ben Hutchings
On Mon, 2018-12-31 at 15:49 +0100, Hans van Kranenburg wrote:
[...]
>   https://wiki.xen.org/wiki/Blktap2
> "Xen blktap2 is a successor to the old blktap1 disk backend driver.
> [...] Xen blktap2 support is included in the Xen version 4.0 released in
> Apr 2010."
> 
> ...the XCP project was stopped in 2013 and this v1 of blktap has been
> obsoleted upstream.
> 
> So, since this dkms was already not usable since Wheezy... What about
> solving this by getting both of them removed from Debian?
[...]

OK, I've opened RM bugs for these two.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman




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


Bug#917907: RM: blktap -- RoQA; obsolete, FTBFS

2018-12-31 Thread Ben Hutchings
Package: ftp.debian.org
Severity: normal

blktap was replaced by blktap2  in
current versions of Xen.  This package FTBFS for a year (#883212).
The related kernel module (blktap-dkms package) was also broken by
kernel API changes around the same time.

Ben.



Bug#917906: linux-image-4.17.0-1-amd64 (and onward): CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 might cause long hangs for user

2018-12-31 Thread Arnaud Rebillout
Package: src:linux
Version: 4.17.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

  Dear kernel maintainers,

starting from `linux-image-4.17.0-1-amd64`, the debian kernel comes
with `CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1` (it was set to `0` before).
  
I wonder if this change was intended, for two reasons.

1. According to the documentation at [1]:

  ``CONFIG_SND_HDA_POWER_SAVE_DEFAULT`` Kconfig options.  Setting this
  to 1 (the minimum value) isn't recommended because many applications
  try to reopen the device frequently.  10 would be a good choice for
  normal operations.

2. Moreover, grepping through the config shows that this change was
only applied to `CONFIG_SND_HDA`, not to `CONFIG_SND_AC97`.

  $ grep POWER_SAVE_DEFAULT config-4.18.0-3-amd64
  CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
  CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1

In any case, this breaks things on my laptop. In short, the function
call `snd_pcm_open()` (to open an audio device), which used to take
around 1 ms, now takes an average of 40 ms, with maximum peaks measured
to 3 seconds.

What's unfortunate is that this function might be called from within
the GTK+ main loop, synchronously, causing apps like the terminal or
a text editor to hang until the call returns. And this function is
called A LOT, due to event sounds.

I described this a bit more in details on the ALSA mailing list at [2].

The kernel documentation at [1] mentions:

  Also, it often takes certain time to wake up from the
  power-down to the active state.  These are often hardly to fix, so
  don't report extra bug reports unless you have a fix patch ;-)

Reading that, and after discovering that event sounds are implemented
synchronously (well, at least using GNOME/Wayland), I wonder if
`CONFIG_SND_HDA_POWER_SAVE_DEFAULT` shouldn't be reverted to 0.

Thanks,

  Arnaud

- 

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sound/designs/powersave.rst
[2]: 
http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143167.html


-BEGIN PGP SIGNATURE-

iQJTBAEBCgA9FiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAlwqLR8fHGFybmF1ZC5y
ZWJpbGxvdXRAY29sbGFib3JhLmNvbQAKCRDnJeh5FGACFuSTD/9dmrbRgG3FfSue
0NPIwSNhV7++OqFZKt9mn3tX9XXrIJnx9SdJLAZ+Tt3R7/uwocdutGUZTT23e2kc
BUoeEPflIevoOOE6ZetdLuUotqa3FvmJMfx/odlGu2zehGkwPzjIJJ3mZ8glYTj2
+/aUi6N4GMgesqhstAAeKgz3/pfz6gWr1uf6fy+OjPSzk+xBU2mOUBvh+Rs34tch
KHUO2ysZ5RwJ73cnqsJcfv4krnF4Rojl5ooijNc5cldxfBdZsN6mfljOnCOFzkgZ
TqG+g0zlY8aGxriDxJwfM1gR9RGXbrVAD++N/KnulSzVK/r4osdtawrnVnbZ38rq
zBQ1O+WvXdWGsERj0Hn7PWHxO6eMo9RBYIFAanwbJceIyiJYxm+Zr3xBtVefEA7D
e5aWUL0AvZpA2ma1bs3xW1IhaGst8mhACu/ef+qbZBqenUfUdfOQ3SNf7wqJQvEe
u1u1O/3JC7qs+By8Kz9hBaIkblZF4IgJ9kCllg9EckTLkg2vU9rR0vyr+2BIidDj
LjmkeFcul52bE1K/azGk+Xjj1L8iGPVFiLrzPjgZOJAI7bkFIFSLYAl8Ucw3p4x5
QGq7yAFLbUgcUJ7MyvRFOEYrRjb/xExtdyG7an8U3IS/1P85FdxuHTQTGtWIPUf7
zZx7p3/ABpZzkT2cM+xRJOMoOzwNeg==
=aX+w
-END PGP SIGNATURE-



Bug#874751: [Pkg-xen-devel] Bug#874751: Processed: severity of 874751 is grave

2018-12-31 Thread Hans van Kranenburg
Hi,

So, this is about:
  https://packages.debian.org/source/sid/blktap-dkms

Related (also with a long living ftbfs bug):
  https://packages.debian.org/source/sid/blktap

I can already tell that while the Debian Xen team is listed as
maintainer, the packages are not anywhere on the radar of the current team.

It seems the packages were added as part of packaging "The Xen Cloud
Platform (XCP)".

According to...
  https://www.xenproject.org/developers/teams/xapi.html
... "Before June 2013, XenServer was not fully open sourced and a subset
of XenServer called XCP was made available [...]"

...and...

  https://wiki.xen.org/wiki/Blktap2
"Xen blktap2 is a successor to the old blktap1 disk backend driver.
[...] Xen blktap2 support is included in the Xen version 4.0 released in
Apr 2010."

...the XCP project was stopped in 2013 and this v1 of blktap has been
obsoleted upstream.

So, since this dkms was already not usable since Wheezy... What about
solving this by getting both of them removed from Debian?

The blktap source package also builds a library to access vhd files...
  https://packages.debian.org/sid/libvhd0
...but there seems to be an alternative for that, if anyone was using it...
  https://packages.debian.org/sid/libvhdi1

Hans



Bug#917905: Fails to build for non-current kernel version

2018-12-31 Thread Ben Hutchings
Package: xtables-addons-source
Version: 3.2-1
Severity: important

When running kernel version 4.18.0-3-amd64 and building for
4.19.0-1-amd64, the build fails:

/usr/bin/make -C /lib/modules/4.19.0-1-amd64/build M=/usr/src/modules/xtables-ad
dons/extensions XA_ABSTOPSRCDIR=/usr/src/modules/xtables-addons XA_TOPSRCDIR=/us
r/src/modules/xtables-addons DEPMOD=/bin/true clean
make[2]: Entering directory '/usr/src/linux-headers-4.19.0-1-amd64'
make[2]: Leaving directory '/usr/src/linux-headers-4.19.0-1-amd64'
dh_prep
dh_clean
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/4.19.0-1-amd64/g'` ; \
  done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} ${templ%.modu
les.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/4.19.0-1-amd64/g ;s/#KVERS#/4.19.0-1-amd64/g ; s/_KVERS_
/4.19.0-1-amd64/g ; s/##KDREV##/4.19.13-1/g ; s/#KDREV#/4.19.13-1/g ; s/_KDREV_/
4.19.13-1/g  ' < $templ > ${templ%.modules.in}; \
  done
dh binary-arch
...
checking kernel version that we will build against... make[2]: *** 
/lib/modules/4.18.0-3-amd64/build: No such file or directory.  Stop.
0.0.0.0 in /lib/modules/4.18.0-3-amd64/build
WARNING: That kernel version is not officially supported.
...
dh_auto_build -- -C /lib/modules/4.19.0-1-amd64/build M=/usr/src/modules/xtables
-addons/extensions XA_ABSTOPSRCDIR=/usr/src/modules/xtables-addons XA_TOPSRCDIR=
/usr/src/modules/xtables-addons DEPMOD=/bin/true
make[3]: Entering directory '/usr/src/linux-headers-4.19.0-1-amd64'
...
make[3]: Leaving directory '/usr/src/linux-headers-4.19.0-1-amd64'
make[2]: Leaving directory '/usr/src/modules/xtables-addons'
make[2]: Entering directory '/usr/src/modules/xtables-addons'
Making check in extensions
make[3]: Entering directory '/usr/src/modules/xtables-addons/extensions'
make -f ../Makefile.iptrules all;
Xtables-addons 3.2 - Linux make[4]: Entering directory 
'/usr/src/modules/xtables-addons/extensions'
make[4]: *** /lib/modules/4.18.0-3-amd64/build: No such file or directory.  
Stop.
make[4]: Leaving directory '/usr/src/modules/xtables-addons/extensions'
make[3]: *** [Makefile:465: modules] Error 2
...

So building the modules is actually successful, but the following
"make check" step fails and ./configure goes wrong because they are
defaulting to the currently running kernel version.

I think you need to add override_dh_auto_configure and
override_dh_auto_test targets to debian/rules that will pass the
target kernel version to the upstream build system.

Ben.

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

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

Versions of packages xtables-addons-source depends on:
ii  bzip2 1.0.6-9
ii  debhelper 12
pn  iptables-dev  
ii  make  4.2.1-1.2
ii  pkg-config0.29-4+b1

Versions of packages xtables-addons-source recommends:
ii  module-assistant  0.11.10

xtables-addons-source suggests no packages.



Bug#917896: Acknowledgement (Method of setting WheelEmulation button, or ScrollButton by user not documented or does not exist.)

2018-12-31 Thread Roger Gammans
Having spend three days without luck looking for settings, I have
another look in dconf after sending the report  and find :

 org/gnome/desktop/peripherals/scroll-wheel-emulation-button

So It a documentation issue at worst..

-- 
Roger Gammans 
Gamma Science Ltd. (GB Nr. 07356014 )



Bug#917713: [Debian-med-packaging] Bug#917713: pyscanfcs: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13

2018-12-31 Thread Andreas Tille
On Mon, Dec 31, 2018 at 02:15:21PM +0100, Alex Mestiashvili wrote:
> 
> thank you for the update, do you think it will make sense to re-upload
> pyscanfcs to trigger rebuild?

There is no need to rebuild since the FTBFS was just on some third
party machine.  Just do a local rebuild and if you can confirm that
the package builds again send an e-mail to
917713-d...@bugs.debian.org
to close the bug.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Bug#847613: ITP: nextcloud-client -- desktop client for nextcloud

2018-12-31 Thread Sandro Knauß
Hey,

> With todays upload of owncloud-client, I got a big fat warning that
> connecting to nextcloud is no longer supported

Argh they now really start fighting against each other - WTF?  If nextcloud-
dektop won't make it to Debian, I'll patch this out.

hefee





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


Bug#915337: rr: baseline violation on i386

2018-12-31 Thread Adrian Bunk
On Sun, Dec 02, 2018 at 11:03:17PM +0100, Stephen Kitt wrote:
> Hi Adrian,

Hi Stephen,

> On Sun, 02 Dec 2018 23:01:23 +0200, Adrian Bunk  wrote:
> > MMX and SSE are not part of the i386 baseline.
> 
> From the package description:
> 
>  rr is incompatible with ptrace hardening, and currently only supports
>  Intel CPUs with Nehalem or later microarchitectures.
> 
> All supported CPUs support MMX and SSE. The package is useful on i386, but I
> can drop it if you think I shouldn’t ship it there.

the cleanest solution would be dropping on i386.

Are there any restriction regarding using amd64 rr with i386 binaries?
During some basic testing this seemed to work for me.

> Regards,
> 
> Stephen

cu
Adrian

-- 

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



Bug#917904: tightvncserver does not ask for password set by vncpasswd

2018-12-31 Thread Jan Christoph Terasa
Package: tightvncserver
Version: 1:1.3.9-9
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I installed tightvncserver on my VPS machine via apt. This did set up 
tightvncserver as an alternative for vncserver. Using a normal user account and
starting vncserver for the first time asks for a 8-letter password. My 
assumption
is this password will be used to authenticate users when connecting to the vnc
server.

After starting the vnc server via vncserver script, it is served on port 5901. 
On the client machine I use vinagre to connect to the server on port 5901. When
connecting, I am not asked for a password, but rather directly taken to the X
session. I would have expected the server to ask for the password I specified
earlier.

As a workaround, to ensure the integrity of the system, I set up iptable rules 
to
not allow direct WAN connections to this port, but only allow local connections
and use an SSH tunnel for connecting to the vnc server.


kind regards,
Christoph


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

Kernel: Linux 4.14.17--std-ipv6-64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages tightvncserver depends on:
ii  libc62.27-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  perl 5.28.0-3
ii  x11-common   1:7.7+19
ii  x11-utils7.7+4
ii  xauth1:1.0.10-1
ii  xserver-common   2:1.20.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages tightvncserver recommends:
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tightvncserver suggests:
pn  tightvnc-java  

-- no debconf information



Bug#917903: init-premount/dropbear reads /etc/dropbear/config instead of /etc/dropbear-initramfs/config

2018-12-31 Thread Arkay Haitsch
Package: dropbear-initramfs
Version: 2016.74-5+deb9u1

the dropbear initramfs-tools init-premount script does include the
config file of the post-initramfs dropbear.

This is likely not desired because when you run dropbear in initramfs
you will usually use a different config (like different port). Of
course there are different options to work around this, e.g.
/etc/initramfs-tools/initramfs.conf, but in my opinion
dropbear-initramfs should use its own config from
/etc/dropbear-initramfs/ instead of relying on the system one from
/etc/dropbear/.

# dpkg -S /usr/share/initramfs-tools/scripts/init-premount/dropbear
dropbear-initramfs: /usr/share/initramfs-tools/scripts/init-premount/dropbear

# dpkg -l dropbear-initramfs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Version Architecture
 Description
+++--===-===-==
ii  dropbear-initramfs
2016.74-5+deb9u1all
 lightweight SSH2 server and client - initramfs integration

# cat /etc/debian_version; uname -a
9.6
Linux debian 4.9.0-8-marvell #1 Debian 4.9.130-2 (2018-10-27) armv5tel GNU/Linux



*** dropbear2018-08-24 02:08:38.0 +0200
--- dropbear.fixed  2018-12-31 15:17:05.569984908 +0100
***
*** 38,44 
  DROPBEAR_OPTIONS="$PKGOPTION_dropbear_OPTION"
  fi
  if [ -e /etc/dropbear/config ]; then
! . /etc/dropbear/config
  fi
  . /scripts/functions

--- 38,44 
  DROPBEAR_OPTIONS="$PKGOPTION_dropbear_OPTION"
  fi
  if [ -e /etc/dropbear/config ]; then
! . /etc/dropbear-initramfs/config
  fi
  . /scripts/functions


Bug#917902: linux-image-4.19.0-1-amd64: Strange X11/Firefox slowdowns/hangs with kernel 4.19

2018-12-31 Thread Uwe Hermann
Package: src:linux
Version: 4.19.13-1
Severity: normal

Hi,

I'm experiencing weird slowdowns/hangs in X11 with
linux-image-4.19.0-1-amd64, reproducible for me with 4.19.13+1 and also
with 4.19.12-1 before that. I didn't test any 4.19.x older than that.

There are no problems when booting the system and there are no problems
when logging into a text console as far as I can tell. When starting
X11 via startx from a text-console there are no problems yet, either.

I can start two xterms, a Gimp, or other programs fine, and I can switch
from one to the other just fine.

The problems start as soon as I start Firefox (64.0-1 currently). When clicking
on e.g. "new tab" it takes ages to make a new tab, or switch from one tab to 
another
or load a website (easily 40 seconds or more). It also takes ages to switch 
from Firefox
to an xterm or Gimp that's already running. Even if the focus is on an xterm 
currently
and I click into another xterm to give it focus, that also takes 40 seconds or 
so.

The mouse cursor itself behaves normal (not slowed down or laggy or anything).

I tried wiping ~/.mozilla to get a default profile, that has the same
problems, though.

After starting X11 only one dmesg item gets logged as far as I can see:

[ 1196.886257] [drm] DM: FBC alloc 5094400

When I "killall -9 firefox" from a text console I get this:

[ 3136.433738] show_signal_msg: 18 callbacks suppressed
[ 3136.433744] Chrome_~dThread[4160]: segfault at 0 ip 7f5610585d01 sp 
7f560a828ab0 error 6
[ 3136.434676] Chrome_~dThread[4141]: segfault at 0 ip 7fe14caedd01 sp 
7fe146da0ab0 error 6
[ 3136.435053]  in libxul.so[7f561056f000+3e8f000]
[ 3136.437242]  in libxul.so[7fe14cad7000+3e8f000]
[ 3136.441992] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48
[ 3136.447029] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48
[ 3136.453812] Chrome_~dThread[4268]: segfault at 0 ip 7fd87c4ddd01 sp 
7fd876790ab0 error 6
[ 3136.453815] Chrome_~dThread[4217]: segfault at 0 ip 7f3e87c5dd01 sp 
7f3e81f00ab0 error 6 in libxul.so[7f3e87c47000+3e8f000]
[ 3136.455530]  in libxul.so[7fd87c4c7000+3e8f000]
[ 3136.457170] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48
[ 3136.458867] Code: 15 d4 dd ae 04 48 89 10 c7 04 25 00 00 00 00 e7 09 00 00 
e8 61 53 ff ff 90 48 8b 05 21 7f f9 05 48 8d 0d 1a de ae 04 48 89 08  04 25 
00 00 00 00
6d 0a 00 00 e8 3f 53 ff ff e8 2a f3 ff ff 48

Even after killing Firefox all other X11 stuff is still horribly slow or
hangs, though. I have to "killall -9 Xorg" and re-run "startx" to get a
working X11 without hangs again.

My current workaround is to boot into an older linux-image-4.18.0-3-amd64
(4.18.20-2) that I've luckily kept around after the dist-upgrade that
installed the current 4.19.x kernel image.

Even though this initially kinda looked like it might be a Firefox bug, the
fact that I can reproducibly boot into 4.18 and everything works fine,
but when booting into 4.19 the issues are reproducible every time,
suggests that it might be kernel or graphics driver related (?)

Cheers, Uwe.

-- Package-specific info:
** Version:
Linux version 4.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.13-1 (2018-12-30)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-1-amd64 root=/dev/mapper/e565--vg-root ro apparmor=1 
security=apparmor vsyscall=emulate

** Not tainted

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

** Model information
sys_vendor: LENOVO
product_name: 20EY000TGE
product_version: ThinkPad E565
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: R01ET27W (1.07 )
board_vendor: LENOVO
board_name: 20EY000TGE
board_version: Not Defined

** Loaded modules:
r8169
libphy
nf_log_ipv6
nf_log_ipv4
nf_log_common
nft_log
nft_counter
nft_ct
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
nf_tables_set
nf_tables
nfnetlink
binfmt_misc
amdkfd
amdgpu
wmi_bmof
edac_mce_amd
kvm_amd
ccp
chash
gpu_sched
snd_hda_codec_conexant
rng_core
ttm
snd_hda_codec_generic
snd_hda_codec_hdmi
kvm
drm_kms_helper
irqbypass
joydev
evdev
serio_raw
pcspkr
drm
snd_hda_intel
fam15h_power
snd_hda_codec
k10temp
snd_hda_core
snd_hwdep
i2c_algo_bit
sp5100_tco
snd_pcm
sg
snd_timer
thinkpad_acpi
nvram
snd
wmi
soundcore
rfkill
ac
battery
video
pcc_cpufreq
button
acpi_cpufreq
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
algif_skcipher
af_alg
dm_crypt
dm_mod
hid_generic
sr_mod

Bug#917457: libilmbase23: 2.3.0-3 bumped so name without transition (breaks digikam, gimp, ...)

2018-12-31 Thread Matteo F. Vescovi
Control: reopen -1

On 2018-12-31 at 11:45 (+01), Eric Valette wrote:

[...]

> Its amazing how people think they can put garbarge in experimental and
> still expecting code to be tested and surprised to discover breakage
> only once they reach unstable.
>
> Breaking gimp,digikam is a major failure...
>
> I do not see the problem with letting the bug and say will not will
> before transition.

So, let's reopen this bug report so that:

 - I can concentrate on its transition
 - you can slumber all night long ;-)

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature


Bug#917901: O: groovebasin -- music player server with a web-based user interface

2018-12-31 Thread Felipe Sateler
Package: wnpp
Severity: normal

The package groovebasin has been orphaned in version 1.4.0-2.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:


 Groove Basin runs on a server optionally connected to speakers. Guests can
 control the music player by connecting with a laptop, tablet, or smart phone.
 Further, users can stream their music libraries remotely.
 .
 Groove Basin comes with a fast, responsive web interface that supports keyboard
 shortcuts and drag drop. It also provides the ability to upload songs,
 download songs, and import songs by URL, including YouTube URLs.
 .
 Groove Basin supports Dynamic Mode which automatically queues random songs,
 favoring songs that have not been queued recently.
 .
 Groove Basin automatically performs ReplayGain scanning on every song using
 the EBU R128 loudness standard, and automatically switches between track
 and album mode.
 .
 Groove Basin supports the MPD protocol, which means it is compatible with MPD
 clients. There is also a more powerful Groove Basin protocol which you can
 use if the MPD protocol does not meet your needs.
 .
 Groove Basin supports Last.fm scrobbling.



  1   2   >