Bug#836458: Cannot edit key stored with an empty passphrase

[Yuri D'Elia]

Package: gnupg
Version: 2.1.15-2
Severity: important

gnupg2 seems to think best that empty passphrases should be abolished.

During the migration from gpg1 to 2, a key previously stored with an empty
passphrase cannot be used anymore:

- attempting to use the key prompts for a passphrase, even though entering an
 empty one is being refused.

- editing the key and using 'passwd' results in the same (the empty passphrase
 is refused when entering the existing passphrase).

I don't understand why this check is put into place.

There are plenty of situations where an empty passphrase is acceptable. Storing
a key encrypted and then having to provide the unencrypted key in unattended
matter (which needs to be stored along with the key anyway) does NOT provide
any added security.

I actually have keyrings of retired keys which I store on encrypted media where
the passphrase has been *intentionally* reset to empty. I cannot access those
keyrings anymore with gpg2.

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

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

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.15-2
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.23-5
ii  libgcrypt201.7.3-1
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.4-4
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  dirmngr 2.1.15-2
pn  gnupg-l10n  

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

Bug#836305: performance regression with modesetting driver on broadwell

[Yuri D'Elia]

Package: xserver-xorg-core
Version: 2:1.18.4-1
Severity: normal

When using the modesetting driver, there's a /significant/ performance 
regression
for many applications.  I can now see libreoffice dialogs *repaint* slowly
(taking 4 seconds to display the preferences dialog in it's entirety!).

Interestingly, using libreoffice-gtk3 makes it useable, but shows several
rendering artifacts which look like misplaced tile offsets, resulting in
currupted text.

Inkscape is also significantly slower, to the point of being unuseable even
with 10 elements in the canvas.

Some other programs seem unaffected.

The same has been true with all the latest 4.6 kernels and now 4.7.

Switching back to the xserver-xorg-video-intel driver fixes the performance
regression.

-- 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:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U 
Integrated Graphics [8086:1616] (rev 09)

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

Contents of /etc/X11/xorg.conf.d:
-
total 0

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

Kernel version (/proc/version):
---
Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20160803 (Debian 5.4.1-1) ) #1 SMP Debian 4.7.2-1 (2016-08-28)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  5738 May  8 18:43 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 54875 Sep  1 15:09 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[19.463] 
X.Org X Server 1.18.4

Release Date: 2016-07-19
[19.463] X Protocol Version 11, Revision 0
[19.463] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[19.463] Current Operating System: Linux eab16011nb 4.7.0-1-amd64 #1 SMP 
Debian 4.7.2-1 (2016-08-28) x86_64
[19.464] Kernel command line: BOOT_IMAGE=/vmlinuz-4.7.0-1-amd64 
root=/dev/mapper/eab16011nb--vg-root ro quiet
[19.464] Build Date: 20 July 2016  05:14:41AM
[19.464] xorg-server 2:1.18.4-1 (http://www.debian.org/support) 
[19.464] Current version of pixman: 0.33.6

[19.464]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[19.464] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[19.464] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep  1 14:21:13 
2016
[19.466] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[19.466] (==) No Layout section.  Using the first Screen section.
[19.466] (==) No screen section available. Using defaults.
[19.466] (**) |-->Screen "Default Screen Section" (0)
[19.466] (**) |   |-->Monitor ""
[19.467] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[19.467] (==) Automatically adding devices
[19.467] (==) Automatically enabling devices
[19.467] (==) Automatically adding GPU devices
[19.467] (==) Max clients allowed: 256, resource mask: 0x1f
[19.470] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[19.470]Entry deleted from font path.
[19.473] (==) 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
[19.473] (==) ModulePath set to "/usr/lib/xorg/modules"
[19.473] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[19.474] (II) Loader magic: 0x55da148abdc0
[19.474] (II) Module ABI versions:
[19.474]X.Org ANSI C Emulation: 0.4
[19.474]X.Org Video Driver: 20.0
[19.474]X.Org XInput driver : 22.1
[19.474]X.Org Server Extension : 9.0
[19.474] (++) using VT number 7

[19.474] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[19.475] (II) xfree86: Adding drm device (/dev/dri/card0)
[19.476] (--) PCI:*(0:0:2:0) 8086:1616:17aa:2227 rev 9, Mem @ 
0xe000/16777216, 0xc000/536870912, I/O @ 0x3000/64, BIOS @ 
0x/131072
[19.476] (II) LoadModule: "glx"
[19.477] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[19.484] (II) Module glx: vendor="X.Org Foundation"
[19.484]compiled for 1.18.4, module version = 1.0.0
[19.484]ABI class: X.Org Server Extension, version 9.0
[

Bug#836204: GTK warnings/errors with GTK3 update

[Yuri D'Elia]

Package: zathura
Version: 0.3.6-2
Severity: normal

As usual, with each GTK3 update, stuff breaks.
I now get the following when I start zathura:

(zathura:24969): Gtk-WARNING **: Theme parsing error: :12:26: Using Pango 
syntax for the font: style property is deprecated; please use CSS syntax
error: Unable to load CSS: :12:8not a number

I assume this is CSS generated by zathura or libgirara-gtk3.

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

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

Versions of packages zathura depends on:
ii  libc62.23-5
ii  libcairo21.14.6-1+b1
ii  libgirara-gtk3-2 0.2.6-1+b1
ii  libglib2.0-0 2.49.6-1
ii  libgtk-3-0   3.21.5-1
ii  libmagic11:5.28-4
ii  libsqlite3-0 3.14.1-1
ii  libsynctex1  2016.20160513.41080-6
ii  zathura-pdf-poppler  0.2.6-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  chromium [www-browser]  52.0.2743.116-2
ii  firefox [www-browser]   49.0~b1-1
ii  w3m [www-browser]   0.5.3-29
pn  zathura-cb  
ii  zathura-djvu0.2.5-1
ii  zathura-ps  0.2.3-1

Bug#834939: Allow to set default policy for debdelta-upgrade

[Yuri D'Elia]

Package: debdelta
Version: 0.55
Severity: wishlist

When I'm using debdelta-upgrade I'm generally behind a slow connection. As a
consequence I never want to download full packages (stuff like tetex would take
months and cost me a fortune).

I'm always using --deb-policy '' to enforce this behavior, but this policy
would better be set somewhere in a configuration file, as it doesn't seem
something that you would change from one invocation to the other.

Thanks

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

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

Versions of packages debdelta depends on:
ii  binutils2.27-6
ii  bzip2   1.0.6-8
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.23-4
ii  python  2.7.11-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages debdelta recommends:
ii  bsdiff   4.3-15
ii  gnupg-agent  2.1.14-5
ii  gnupg2   2.1.14-5
ii  python-apt   1.1.0~beta4
ii  python-debian0.1.29
ii  xdelta   1.1.3-9.1
ii  xdelta3  3.0.11-dfsg-1
ii  xz-utils [lzma]  5.1.1alpha+20120614-2.1

Versions of packages debdelta suggests:
ii  debdelta-doc  0.55

-- Configuration Files:
/etc/debdelta/sources.conf changed [not included]

Bug#814289: python3-pdfrw: wrongly provides/conflicts (python-)pdfrw

[Yuri D'Elia]

Package: python-pdfrw
Version: 0.2-2
Followup-For: Bug #814289

I'm affected by this. It makes python-pdfrw and python3-pdfrw not 
co-installable.

It also breaks a host of other packages as a consequence. You cannot install
rst2pdf and ocrmypdf together.

Bug#814808: libboost-doc depends on g++/g++-5

[Yuri D'Elia]

Package: libboost-doc
Version: 1.61.0.1
Followup-For: Bug #814808

Version 1.61.0.1 now depends on gcc-5 >= 6.1.1-9 which is obviously broken,
making this package uninstallable.

Please do not depend on g++/g++-5 for -doc.

Bug#832363: "forget-new" with minibuffer-style prompt looks broken

[Yuri D'Elia]

Package: aptitude
Version: 0.8.2-1
Severity: normal

The new 'forget-new' query dialog looks broken if
'aptitude::UI::Minibuf-Prompts' is true.

-- Package-specific info:
Terminal: rxvt-unicode-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.2
Compiler: g++ 5.4.0 20160609
Compiled against:
 apt version 5.0.0
 NCurses version 6.0
 libsigc++ version: 2.8.0
 Gtk+ support disabled.
 Qt support disabled.

Current library versions:
 NCurses version: ncurses 6.0.20160625
 cwidget version: 0.5.17
 Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd1d5f8000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f5476a76000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f5476846000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f547661b000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f5476414000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f5476117000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f5475e12000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f5475bf8000)
libboost_filesystem.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7f54759df000)
libboost_system.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7f54757da000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7f54753d6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f54751b9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f5474e38000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5474b33000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f547491d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f547457b000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f5474378000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5474174000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f5473f5c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5473d41000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f5473b31000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f547390d000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f54736fb000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f54734f2000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f54732ed000)
/lib64/ld-linux-x86-64.so.2 (0x55b7f0e36000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.2-1
ii  libapt-pkg5.0  1.3~pre2
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5.1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5.1
ii  libboost-system1.58.0  1.58.0+dfsg-5.1
ii  libc6  2.23-2
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.1.1-9
ii  libncursesw5   6.0+20160625-1
ii  libsigc++-2.0-0v5  2.8.0-1
ii  libsqlite3-0   3.13.0-1
ii  libstdc++6 6.1.1-9
ii  libtinfo5  6.0+20160625-1
ii  libxapian22v5  1.2.23-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-10
ii  sensible-utils 0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index0.48
pn  aptitude-doc-en | aptitude-doc  
ii  debtags 2.1.1
pn  tasksel 

Bug#832010: Please enable LZ4 compression

[Yuri D'Elia]

On Fri, Jul 22 2016, Michael Biebl  wrote:
> So, this is the main reason I'm worried about enabling lz4 support.
> Afair, it's not runtime configurable, so each new journal entry would be
> lz4 compressed, which effectively means we will have to use lz4 forever
> (which has quite a considerable worse compression).

Depending on the scenario, the performance of XZ might be inadequate
though.

For coredump I had to disable compression to avoid a nosedive in
performance at each crash. Even though LZ4 is not optimal, it still
makes a great difference compared to no compression, especially for core
files, and it's an "accepted" tradeoff for this kind of scenario.

I initially filed an RFE directly upstream to request LZ4, only to
discover it was already a new default but not available in debian.

> If lz4 support was runtime configurable and explicitly opt-in by the
> admin, I wouldn't be as concerned.

With the performance of XZ, I would be cautious to use it as the default
journal compression format either. journald is pretty [damn] slow
already without compression.

For an aggregation host maybe, but not for the current system.

> As it stands today, I don't want to make lz4 our new default.

I understand the concern. I similarly requested a tunable to select the
compression method, but I guess patches are the most welcomed request...

If somebody has the time, it doesn't look like a complicated task.
"compress.h" is very simplistic right now.

But I'd keep in mind that LZ4 seems to be a more reasonable choice
compared to XZ for both the journal and coredump.

Bug#832010: Please enable LZ4 compression

[Yuri D'Elia]

On Thu, Jul 21 2016, Michael Biebl  wrote:
> And in Debian we build against libxz, so xz compression is used for core
> files.

Indeed, and it's pretty slow.

> What would we gain by switching from xz to lz4. Can you provide numbers?

I don't have enough time to back it up comparing exactly the difference
between LZ4 and XZ in coredump, but if you compare regular XZ to LZ4 you
can expect anywhere between 10x and 50x improvement in compression
speed while maintaining an acceptable compression ratio.

Bug#832010: Please enable LZ4 compression

[Yuri D'Elia]

On Thu, Jul 21 2016, Michael Biebl  wrote:
>>> LZ4 is the default compression method according to upstream since systemd
>>> 229.
>
> What exactly do you mean by "default"?
> Afaics, the default is no compression at all.

For journal entries probably not, but for core files compression is on
by default.

> If we build against liblz4, what happens with existing journal files?

By reading briefly through the code, if both lz4 and xz are available,
both will be read but new entries will be compressed directly with lz4.

> What happens with existing journal files, if it turns out that the LZ4
> compression causes problems and we have to disable it again?

Cannot answer this, but if we turn it on it should likely stay on.
Likewise, we cannot remove XZ support for the same reason (reading old entries).

Bug#832010: Please enable LZ4 compression

[Yuri D'Elia]

Package: systemd-coredump
Version: 230-7
Severity: wishlist

LZ4 compression makes a huge difference in terms of performance impact when
compressing core files, but it's currently not enabled (I guess due to missing
LZ4 dependency?).

LZ4 is the default compression method according to upstream since systemd 229.

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

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

Versions of packages systemd-coredump depends on:
ii  adduser  3.115
ii  libacl1  2.2.52-3
ii  libc62.23-2
ii  libdw1   0.165-3
ii  libelf1  0.165-3
ii  systemd  230-7

systemd-coredump recommends no packages.

systemd-coredump suggests no packages.

Bug#831687: Python 3 support

[Yuri D'Elia]

Package: tulip
Version: 4.8.0dfsg-2+b4
Severity: normal

The python module bundled with tulip is only built for python 2.7
Tulip mentions already compatibility with python 3, so please build the module 
also for python 3.
Thanks.

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

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

Versions of packages tulip depends on:
ii  binutils  2.26.1-1
ii  fonts-dejavu-core 2.36-1
ii  fonts-font-awesome4.6.3~dfsg-1
ii  libc6 2.23-1
ii  libfreetype6  2.6.3-3+b1
ii  libftgl2  2.1.3~rc5-4+nmu1+b1
ii  libgcc1   1:6.1.1-9
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglew1.13   1.13.0-2
ii  libgzstream-tulip-4.8-0   4.8.0dfsg-2+b4
ii  libjpeg62-turbo   1:1.5.0-1
ii  libogdf-tulip-4.8-0   4.8.0dfsg-2+b4
ii  libpng16-16   1.6.23-1
ii  libpython2.7  2.7.12-1
ii  libqt5core5a  5.6.1+dfsg-3
ii  libqt5gui55.6.1+dfsg-3
ii  libqt5network55.6.1+dfsg-3
ii  libqt5opengl5 5.6.1+dfsg-3
ii  libqt5webkit5 5.6.1+dfsg-4
ii  libqt5widgets55.6.1+dfsg-3
ii  libqt5xml55.6.1+dfsg-3
ii  libqt5xmlpatterns55.6.1-2
ii  libquazip-tulip-4.8-1 4.8.0dfsg-2+b4
ii  libqxt-tulip-4.8-04.8.0dfsg-2+b4
ii  libstdc++66.1.1-9
ii  libtess2-tulip-4.84.8.0dfsg-2+b4
ii  libtulip-core-4.8 4.8.0dfsg-2+b4
ii  libtulip-gui-4.8  4.8.0dfsg-2+b4
ii  libtulip-ogdf-4.8 4.8.0dfsg-2+b4
ii  libtulip-ogl-4.8  4.8.0dfsg-2+b4
ii  libtulip-python-4.8   4.8.0dfsg-2+b4
ii  libyajl-tulip-4.8-2   4.8.0dfsg-2+b4
ii  zlib1g1:1.2.8.dfsg-2+b1

tulip recommends no packages.

tulip suggests no packages.

Bug#831561: Needs rebuild for dovecot 2.2.25

[Yuri D'Elia]

Package: dovecot-antispam
Version: 2.0+20150222-1+b4
Severity: normal

dovecot-antispam needs to be rebuilt for dovecot 2.2.25.
It's currently uninstallable.

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

Kernel: Linux 3.4.108-kvm-i386-20150619
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dovecot-antispam depends on:
ii  dovecot-core [dovecot-abi-2.2.abiv24]  1:2.2.24-1
ii  dovecot-imapd  1:2.2.24-1
ii  libc6  2.23-1

dovecot-antispam recommends no packages.

Versions of packages dovecot-antispam suggests:
pn  crm114 | dspam  

Bug#830985: tulip: error while loading shared libraries: libbfd-2.26-system.so

[Yuri D'Elia]

On Sat, Jul 16 2016, ydir...@free.fr wrote:
>> Seems like tulip depends on libbfd-2.26-system.so, but only
>> libbfd-2.26-system.so.1 is available on my system.
>
> You mean "libbfd-2.26.1-system.so", right ?

Indeed, just a typo in my part.

Bug#830998: mingle not built

[Yuri D'Elia]

Package: graphviz
Version: 2.38.0-14
Severity: normal

graphviz 2.38 should also include 'mingle', but it's not currently built since
it depends on the ANN library.

Since it is available, could you build-depend also on libann to build this tool
correctly?

Thanks.

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

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

Versions of packages graphviz depends on:
ii  libc6 2.23-1
ii  libcdt5   2.38.0-14
ii  libcgraph62.38.0-14
ii  libexpat1 2.2.0-1
ii  libglib2.0-0  2.48.1-1
ii  libgts-0.7-5  0.7.6+darcs121130-1.2
ii  libgvc6   2.38.0-14
ii  libgvpr2  2.38.0-14
ii  libx11-6  2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1

Versions of packages graphviz recommends:
ii  fonts-liberation  1.07.4-1

Versions of packages graphviz suggests:
ii  graphviz-doc  2.38.0-14
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.2

Bug#830985: tulip: error while loading shared libraries: libbfd-2.26-system.so

[Yuri D'Elia]

Package: tulip
Version: 4.8.0dfsg-2+b3
Severity: important

Seems like tulip depends on libbfd-2.26-system.so, but only 
libbfd-2.26-system.so.1 is available on my system.

% tulip
tulip: error while loading shared libraries: libbfd-2.26-system.so: cannot open 
shared object file: No such file or directory

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

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

Versions of packages tulip depends on:
ii  binutils  2.26.1-1
ii  fonts-dejavu-core 2.35-1
ii  fonts-font-awesome4.6.3~dfsg-1
ii  libc6 2.23-1
ii  libfreetype6  2.6.3-3+b1
ii  libftgl2  2.1.3~rc5-4+nmu1+b1
ii  libgcc1   1:6.1.1-9
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglew1.13   1.13.0-2
ii  libgzstream-tulip-4.8-0   4.8.0dfsg-2+b3
ii  libjpeg62-turbo   1:1.5.0-1
ii  libogdf-tulip-4.8-0   4.8.0dfsg-2+b3
ii  libpng16-16   1.6.23-1
ii  libpython2.7  2.7.12-1
ii  libqt5core5a  5.6.1+dfsg-3
ii  libqt5gui55.6.1+dfsg-3
ii  libqt5network55.6.1+dfsg-3
ii  libqt5opengl5 5.6.1+dfsg-3
ii  libqt5webkit5 5.6.1+dfsg-4
ii  libqt5widgets55.6.1+dfsg-3
ii  libqt5xml55.6.1+dfsg-3
ii  libqt5xmlpatterns55.6.1-2
ii  libquazip-tulip-4.8-1 4.8.0dfsg-2+b3
ii  libqxt-tulip-4.8-04.8.0dfsg-2+b3
ii  libstdc++66.1.1-9
ii  libtess2-tulip-4.84.8.0dfsg-2+b3
ii  libtulip-core-4.8 4.8.0dfsg-2+b3
ii  libtulip-gui-4.8  4.8.0dfsg-2+b3
ii  libtulip-ogdf-4.8 4.8.0dfsg-2+b3
ii  libtulip-ogl-4.8  4.8.0dfsg-2+b3
ii  libtulip-python-4.8   4.8.0dfsg-2+b3
ii  libyajl-tulip-4.8-2   4.8.0dfsg-2+b3
ii  zlib1g1:1.2.8.dfsg-2+b1

tulip recommends no packages.

tulip suggests no packages.

Bug#794650: pulseaudio: please ship the pulseaudio equalizer UI (qpaeq)

[Yuri D'Elia]

Package: pulseaudio
Version: 9.0-1
Followup-For: Bug #794650

I would second having a separate pulseaudio-qpaeq, as well as moving the actual
plugin (so) to this package.

Having the equalizer plugin without having the interface to control it is
completely useless.

Bug#828051: Should Suggest: nim-doc

[Yuri D'Elia]

Source: nim
Severity: whishlist

It would be nice if nim suggested it's own documentation.

Thanks

Bug#827756: Cannot enable lingering without policykit-1

[Yuri D'Elia]

On Mon, Jun 20 2016, Felipe Sateler  wrote:
>> $ loginctl enable-linger Could not enable linger: The name
>> org.freedesktop.PolicyKit1 was not provided by any .service files
>>
>> I guess systemd should now Recommend policykit-1 as well.
>
> Recommends is a bit too strong. You can still use most of systemd
> without policykit, and even enable lingering if you run it as root.
>
> But I think Suggests is appropriate.

Absolutely happy with that.

Bug#827756: Cannot enable lingering without policykit-1

[Yuri D'Elia]

Package: systemd
Version: 230-2
Severity: normal
File: /bin/loginctl

On a test system I tried to enable lingering for an user, but got the following:

$ loginctl enable-linger 
Could not enable linger: The name org.freedesktop.PolicyKit1 was not provided by any .service files


I guess systemd should now Recommend policykit-1 as well.

Bug#827734: Suggests non-existing freecad-doc package

[Yuri D'Elia]

Package: freecad
Version: 0.16+dfsg2-1
Severity: minor

Looks like that freecad-doc is, sadly, no longer built?
In this case, the Suggests needs to be dropped.

Bug#660248: Qtractor 0.7.7 -released

[Yuri D'Elia]

On Fri, Jun 17 2016, Jaromír Mikeš  wrote:
> Hi,
>
> (Now send also to submitters)
> can you please confirm that this bug still exists in new 0.7.7 release of 
> Qtractor?
> (Just uploaded)
> If not I would like to close this bug.

I didn't use qtractor recently (mostly muse), so please close for me.
I'll re-open if necessary.

Bug#779990: gwave: Segmentation fault on startup

[Yuri D'Elia]

Package: gwave
Version: 20090213-6
Followup-For: Bug #779990

Still crashes on startup, apparently when starting guile.

% gdb =gwave
Reading symbols from /usr/bin/gwave...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/gwave 
[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffefc16700 (LWP 21869)]
[New Thread 0x7fffef415700 (LWP 21870)]
[New Thread 0x7fffeec14700 (LWP 21871)]

Program received signal SIGSEGV, Segmentation fault.
0x0040ff81 in ?? ()
(gdb) bt
#0  0x0040ff81 in ?? ()
#1  0x76ac6383 in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#2  0x76a3286e in scm_call_3 () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#3  0x76aabc2e in scm_internal_catch () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#4  0x76a2ca48 in scm_internal_stack_catch () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#5  0x76ac6383 in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#6  0x76a3286e in scm_call_3 () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#7  0x76a29371 in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#8  0x76a85455 in scm_internal_cwdr () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#9  0x0040fd33 in ?? ()
#10 0x004094f8 in ?? ()
#11 0x0040b9cf in ?? ()
#12 0x76a502ad in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#13 0x76a28bda in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#14 0x76ac6383 in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#15 0x76a328d3 in scm_call_4 () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#16 0x76a29371 in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#17 0x76a29455 in scm_c_with_continuation_barrier () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#18 0x76aa920c in ?? () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#19 0x72a673c2 in GC_call_with_stack_base () from 
/usr/lib/x86_64-linux-gnu/libgc.so.1
#20 0x76aa9638 in scm_with_guile () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#21 0x76a50485 in scm_boot_guile () from 
/usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#22 0x004066bb in ?? ()
#23 0x75dec5f0 in __libc_start_main (main=0x406690, argc=1, argv=0x7fffe2b8, 
init=, fini=, rtld_fini=, 
stack_end=0x7fffe2a8) at libc-start.c:291
#24 0x004066f9 in ?? ()

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

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

Versions of packages gwave depends on:
ii  guile-2.0-libs 2.0.11+1-10+b1
ii  guile-gnome2-glib  2.16.2-2
ii  guile-gnome2-gtk   2.16.2-2
ii  libc6  2.22-11
ii  libglib2.0-0   2.48.1-1
ii  libgtk2.0-02.24.30-2
ii  libreadline6   6.3-8+b4
ii  libx11-6   2:1.6.3-1

Versions of packages gwave recommends:
pn  extra-xdg-menus  

gwave suggests no packages.

Bug#826873: Should Suggest: ngspice-doc

[Yuri D'Elia]

Package: ngspice
Version: 26-1.1
Severity: wishlist

It would be nice if ngspice would Suggest it's own documentation.
Thanks.

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

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

Versions of packages ngspice depends on:
ii  dpkg  1.18.7
ii  install-info  6.1.0.dfsg.1-8
ii  libc6 2.22-11
ii  libedit2  3.1-20150325-1+b1
ii  libice6   2:1.0.9-1+b1
ii  libncurses5   6.0+20160319-1
ii  libsm62:1.2.2-1+b1
ii  libtinfo5 6.0+20160319-1
ii  libx11-6  2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxext6  2:1.3.3-1
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1

ngspice recommends no packages.

ngspice suggests no packages.

Bug#826581: Issues with the builtin modesetting driver + broadwell graphics

[Yuri D'Elia]

Package: xserver-xorg
Version: 1:7.7+15
Severity: important

I'm not sure where I should report this, but I've tried several times to use
the modesetting driver with Intel Broadwell graphics, but I have issues with
the screen "flickering" randomly.

The visible output shifts left-right from a certain horizontal point onward, in
bursts of a tenth of a second, and then quickly settles again. This happens
most frequently on the second monitor output when it's connected, but it also
happens on the main display, even when there's only one output connected (the
laptop screen itself).

This issue was a major problem with the 4.4 kernel and an older Xorg version
(where flickering was continuous), making the modesetting driver unusable.
Starting with 4.5 (and a newer Xorg) it seem to have improved. Is this a kernel
issue, drm issue, ...?  I'm currently trying 4.6, with no difference compared
to 4.5 (same frequency in the flickering issue).

There's no output in dmesg or in the Xorg log. This makes using the modesetting
driver throughout the day nerve-wracking, and I'm giving up.

On top of that, the modesetting driver makes widget repaiting in
libreoffice-gtk incredibly slow. You can see widgets being repainted, with the
preferences dialog taking 2-3 seconds to draw itself. Interestingly, I didn't
experience this issue with other gtk2-based programs.

Switching to the video-intel driver fixes both issues (no flickering, no slow
libreoffice-gtk repaint), but it's not issue-free. GL programs and gtk3 in
general show occasional spot corruptions of blocks of ~16x16 pixels which seem
to have been blitted to the wrong spot, often making text unreadable.

-- 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:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U 
Integrated Graphics [8086:1616] (rev 09)

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

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

Kernel version (/proc/version):
---
Linux version 4.6.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
5.3.1 20160509 (Debian 5.3.1-19) ) #1 SMP Debian 4.6-1~exp1 (2016-05-17)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 61458 Jun  6 15:53 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[11.577] 
X.Org X Server 1.18.3

Release Date: 2016-04-04
[11.577] X Protocol Version 11, Revision 0
[11.577] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[11.577] Current Operating System: Linux eab16011nb 4.6.0-trunk-amd64 #1 
SMP Debian 4.6-1~exp1 (2016-05-17) x86_64
[11.577] Kernel command line: BOOT_IMAGE=/vmlinuz-4.6.0-trunk-amd64 
root=/dev/mapper/eab16011nb--vg-root ro quiet
[11.577] Build Date: 05 April 2016  07:00:43AM
[11.577] xorg-server 2:1.18.3-1 (http://www.debian.org/support) 
[11.577] Current version of pixman: 0.33.6

[11.577]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[11.577] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[11.577] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jun  6 12:17:02 
2016
[11.581] (==) Using config directory: "/etc/X11/xorg.conf.d"
[11.581] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[11.583] (==) No Layout section.  Using the first Screen section.
[11.583] (==) No screen section available. Using defaults.
[11.583] (**) |-->Screen "Default Screen Section" (0)
[11.583] (**) |   |-->Monitor ""
[11.584] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[11.584] (**) |   |-->Device "intel"
[11.584] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[11.584] (==) Automatically adding devices
[11.584] (==) Automatically enabling devices
[11.584] (==) Automatically adding GPU devices
[11.584] (==) Max clients allowed: 256, resource mask: 0x1f
[11.587] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[11.587]Entry deleted from font path.
[11.589] (==) 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
[11.589] (==) ModulePath set to "/usr/lib/xorg/modules"
[11.589] (II) The server relies on udev to provide the list of input 
devices.
If no 

Bug#825499: Info received ([php-maint] Bug#825499: Fails to start)

[Yuri D'Elia]

On Fri, May 27 2016, Debian Bug Tracking System  wrote:
> If you wish to submit further information on this problem, please
> send it to 825...@bugs.debian.org.

By the way, I only needed to remove PrivateDevices for this specific
issue, and was able to run larger packages (such as roundcube)
successfully.

ProtectSystem and PrivateTmp didn't seem to interfere.

I only write this as I see they also got removed, but maybe it wasn't
necessary.

Bug#825499: [php-maint] Bug#825499: Fails to start

[Yuri D'Elia]

On Fri, May 27 2016, Ondřej Surý  wrote:
> JFTR is this a bare system or container?

Bare system.

Bug#825500: Please switch php-pspell dependency to Recommends

[Yuri D'Elia]

Package: roundcube
Version: 1.2.0+dfsg.1-1
Severity: minor

Given only one plugin actually needs pspell, I would advocate to downgrade the
current dependency of php-spell to a Recommends instead.

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

Kernel: Linux 3.4.108-kvm-i386-20150619
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages roundcube-plugins depends on:
ii  dpkg1.18.7
ii  php7.0-pspell [php-pspell]  7.0.7-1
ii  roundcube-core  1.2.0+dfsg.1-1

roundcube-plugins recommends no packages.

roundcube-plugins suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.4
ii  debconf [debconf-2.0]   1.5.59
ii  dpkg1.18.7
ii  libmagic1   1:5.25-2
ii  php-auth-sasl   1.0.6-3
ii  php-cli 1:7.0+41
ii  php-common  1:41
ii  php-crypt-gpg   1.4.1-1
ii  php-intl1:7.0+41
ii  php-json1:7.0+41
ii  php-mail-mime   1.10.0-2
ii  php-mcrypt  1:7.0+41
ii  php-net-smtp1.7.1-2
ii  php-net-socket  1.0.14-2
ii  php-pear1:1.10.1+submodules+notgz-8
ii  php7.0 [php]7.0.7-1
ii  php7.0-cli [php-cli]7.0.7-1
ii  php7.0-intl [php-intl]  7.0.7-1
ii  php7.0-json [php-json]  7.0.7-1
ii  php7.0-mcrypt [php-mcrypt]  7.0.7-1
ii  roundcube-sqlite3   1.2.0+dfsg.1-1
ii  ucf 3.0036

Versions of packages roundcube-core recommends:
ii  lighttpd [httpd-cgi]1.4.39-1
ii  nginx-light [httpd-cgi] 1.10.0-1
ii  php-fpm 1:7.0+41
pn  php-gd  
ii  php7.0-fpm [php-fpm]7.0.7-1
ii  php7.0-pspell [php-pspell]  7.0.7-1

Versions of packages roundcube-core suggests:
pn  php-net-ldap2  
pn  php-net-ldap3  

Versions of packages roundcube depends on:
ii  dpkg1.18.7
ii  roundcube-core  1.2.0+dfsg.1-1

Bug#825499: Fails to start

[Yuri D'Elia]

Package: php7.0-fpm
Version: 7.0.7-1
Severity: normal

With the latest update, php7.0-fpm fails to start with the following error 
message:

php-fpm7.0[6505]: [27-May-2016 11:37:30] ERROR: failed to init stdio: 
open("/dev/null"): Permission denied (13)

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

Kernel: Linux 3.4.108-kvm-i386-20150619
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php7.0-fpm depends on:
ii  init-system-helpers  1.33
ii  libapparmor1 2.10-4
ii  libc62.22-9
ii  libmagic11:5.25-2
ii  libpcre3 2:8.38-3.1
ii  libssl1.0.2  1.0.2h-1
ii  libsystemd0  230-1
ii  libxml2  2.9.3+dfsg1-1
ii  mime-support 3.60
ii  php7.0-cli   7.0.7-1
ii  php7.0-common7.0.7-1
ii  php7.0-json  7.0.7-1
ii  php7.0-opcache   7.0.7-1
ii  tzdata   2016d-2
ii  ucf  3.0036
ii  zlib1g   1:1.2.8.dfsg-2+b1

php7.0-fpm recommends no packages.

Versions of packages php7.0-fpm suggests:
ii  php-pear  1:1.10.1+submodules+notgz-8

Versions of packages php7.0-common depends on:
ii  libc62.22-9
ii  libssl1.0.2  1.0.2h-1
ii  php-common   1:41
ii  ucf  3.0036

Bug#825310: Cannot import urllib3.contrib.appengine

[Yuri D'Elia]

Package: python3-urllib3
Version: 1.15.1-1
Severity: normal

| >>> from requests.packages.urllib3.contrib import appengine
| Traceback (most recent call last):
|   File "", line 1, in 
|   File "/usr/lib/python3/dist-packages/urllib3/contrib/appengine.py", line 15, in 

| from ..packages.six import BytesIO
| ImportError: No module named 'requests.packages.urllib3.packages.six'

This ImportError makes python3-requests-toolbelt fail during import.

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

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

Versions of packages python3-urllib3 depends on:
ii  python3-six  1.10.0-3
pn  python3:any  

Versions of packages python3-urllib3 recommends:
ii  ca-certificates  20160104

Versions of packages python3-urllib3 suggests:
pn  python3-ndg-httpsclient  
pn  python3-openssl  
pn  python3-pyasn1   
pn  python3-socks

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

On Sat, May 21 2016, Laurent Bigonville <bi...@debian.org> wrote:
> Le 21/05/16 à 21:53, Yuri D'Elia a écrit :
>> Sorry for the delay, but I wanted to actually give it a try before
>> giving feedback.
>>
>> Indeed, that obviously fixes the problem.
>>
>> So is this actually a patch local to debian now?
> Thanks for the feedback.
>
> Yes, I cherry-picked the patch from upstream to have it immediately in
> debian, it's in unstable for a few days now.

I noticed right after your reply, but couldn't get to it right away.
Thanks a lot for this.

I do believe this is the _right_ approach.

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

On Fri, May 13 2016, Laurent Bigonville  wrote:
> Can you please try the patch that has been attached to the bug and tell
> me if it's fixing your issue?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823184#44

Sorry for the delay, but I wanted to actually give it a try before
giving feedback.

Indeed, that obviously fixes the problem.

So is this actually a patch local to debian now?

Bug#805901: cmake: suggest cmake-doc

[Yuri D'Elia]

Package: cmake
Version: 3.5.2-1
Followup-For: Bug #805901

Yes, it would be nice if every package suggested it's own documentation when 
available.

Thanks

Bug#791662: aptitude: debdelta integration

[Yuri D'Elia]

On Wed, May 18 2016, Julian Andres Klode  wrote:
> On Wed, May 18, 2016 at 01:59:22PM +0200, A Mennucc1 wrote:
>> But keep in mind that debdelta is integrated in 'cupt' that is another
>> package manager, similar to 'aptitude'.

The main selling point of aptitude for me is the sophisticated curses
interface and it's preview. I wouldn't bother using aptitude if it
wasn't for it's TUI (in fact, I use apt-get directly in other
scenarios).

> 1. An index of all deltas (probably per-arch) with checksums for them
>(basically that's old hash, new hash, delta hash, and size. hashes
> should be SHA256 or SHA512). Preferably also Package, Version,
>Old-Version, Architecture fields.
> 2. A release file signing the index

Do we need all of those? A reconstructed package is byte-for-byte
identical to the package already in the pool. We can verify the
authenticity using the original archive signature before installing it.

I don't know if debdelta has already delta checksums themselves (mainly
to prevent corruption over transfer).

Please correct me if I'm wrong.

> We want to have that for security reasons (we do not
> want to trust unsigned data), and of course for progress display
> (we need to know how many files to fetch and how large they are).

This should also be already available.

> I'm still not sure if debdelta is the right approach, or if we can
> come up with something faster.

Downloading deltas is a CPU/space tradeoff. Over a fast link, rebuilding
the package with the delta is going to take longer than simply
redownloading it in full.

Which is the main reason we need a controllable switch in the frontend.

Bug#824506: overlay scrollbars do not work properly

[Yuri D'Elia]

On Mon, May 16 2016, Michael Biebl  wrote:
>> I see the handle being highlighted, but as soon as I click on it on a spot
>> which is beyond the original (thin) size, the bar disappears and I'm
>> dragging
>> the content of the underlying widget.
>
> Fwiw, I can not confirm your findings here.
> I can grab the scrollbar using its full width.
>
> Maybe your gtk settings.ini modifications messed something up.

I tried with a fresh user account, so no user settings that I'm aware
of.

Are you aware of anything else that might be affecting gtk here?

Bug#824506: overlay scrollbars do not work properly

[Yuri D'Elia]

On Mon, May 16 2016, Michael Biebl  wrote:
>> I generally like the idea of overlay scrollbars, but somehow the current
>> implementation in GTK3 shouldn't have passed QA for basic usability.
>
> Thanks for your bug reports. Please consider filing such issues directly
> upstream [1]. Downstream is really the wrong place for this

I will, however for some class of bugs that affect general system
usability (and the system as a whole), I also file reports downstream.

Bug#824506: overlay scrollbars do not work properly

[Yuri D'Elia]

Package: libgtk-3-0
Version: 3.20.4-1
Severity: important

I generally like the idea of overlay scrollbars, but somehow the current
implementation in GTK3 shouldn't have passed QA for basic usability.

I'm trying gtk3 with the stock Adwaita theme to avoid issues.

When I mouseover the right corner of a widget with an overlay scrollbar, the
bar widens and the scrollbar is revealed in it's full width.

If I click on the right-most side (on the spot where the scrollbar was already
visible), I can drag to grab the handle of the scrollbar. Ok.

However, I'm not expected to be able to hit a 3px wide bar here.  The
interaction should be: move over it, the bar widens for a few m/s and now you
can hit a bigger target more reliably.

Once the bar widens to reveal it's full width, I *MUST* be able to click
anywhere on the handle in order to grab it. Just like a regular scrollbar.

But It's not the case.

I see the handle being highlighted, but as soon as I click on it on a spot
which is beyond the original (thin) size, the bar disappears and I'm dragging
the content of the underlying widget. Are you /kidding/ me? This feels like the
same crap you see in web pages.

I can only reliably click on the right-most edge, with a scrollbar now so thin
it's hardly usable at all. I love the concept, but this is broken.

On top of that, I look on how I can disable this. Fortunately, it seems
possible, but only though an environment variable. There's no setting in the
main gtk3 setting.ini file??

Sigh

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

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

Versions of packages libgtk-3-0:amd64 depends on:
ii  libatk-bridge2.0-0  2.20.1-1
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-9
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.3.2-1
ii  libcups22.1.3-5
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.4
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.1-1
ii  libgtk-3-common 3.20.4-1
ii  libjson-glib-1.0-0  1.2.0-1
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libpangoft2-1.0-0   1.40.1-1
ii  librest-0.7-0   0.8.0-1
ii  libsoup2.4-12.54.1-1
ii  libwayland-client0  1.10.0-2
ii  libwayland-cursor0  1.10.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  11.2.2-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxml2 2.9.3+dfsg1-1
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.6-1

Versions of packages libgtk-3-0:amd64 recommends:
ii  libgtk-3-bin  3.20.4-1

Versions of packages libgtk-3-0:amd64 suggests:
pn  gvfs 
ii  librsvg2-common  2.40.15-1

Bug#824505: Setting gtk-enable-animations=false doesn't disable overscroll effect

[Yuri D'Elia]

Package: libgtk-3-0
Version: 3.20.4-1
Severity: normal

I noticed that GTK3 does not respect the gtk-enable-animations=false property
completely.

The overscroll effect is still visible at least in the GtkScrolledWindow widget
when scrolling events are being used.

Pretty please, respect this setting.
Thanks

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

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

Versions of packages libgtk-3-0 depends on:
ii  libatk-bridge2.0-0  2.20.1-1
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-9
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.3.2-1
ii  libcups22.1.3-5
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.4
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.1-1
ii  libgtk-3-common 3.20.4-1
ii  libjson-glib-1.0-0  1.2.0-1
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libpangoft2-1.0-0   1.40.1-1
ii  librest-0.7-0   0.8.0-1
ii  libsoup2.4-12.54.1-1
ii  libwayland-client0  1.10.0-2
ii  libwayland-cursor0  1.10.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  11.2.2-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxml2 2.9.3+dfsg1-1
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.6-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.20.4-1

Versions of packages libgtk-3-0 suggests:
pn  gvfs 
ii  librsvg2-common  2.40.15-1

Bug#824404: Should Suggest: python-hypothesis-doc

[Yuri D'Elia]

Package: python3-hypothesis
Version: 3.1.0-1
Severity: wishlist

It would be nice if python3-hypothesis (and the python 2 package) suggested
it's own documentation.

Thanks

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

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

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

On Fri, May 13 2016, Laurent Bigonville  wrote:
> Again this is supposed to happen at early boot, and at this stage, only
> PID1 exists. So I doubt there is a lot of concurrent processes at that time.

But this is not checked in the source.
In fact, this behavior will happen irregardless of the boot stage.

>> Even if the fix is simply the removal of the mountpoint, I consider the
>> solution broken by design.
> What about mounting /proc really early?

I can say the same about initramfs. Can't initramfs just mount /proc
sooner and fix the problem correctly?

>  Mount failed for selinuxfs on /sys/fs/selinux:  No such file or
> directory
>
>  To fix this, mount the procfs before attempting to open
>  /proc/filesystems, and unmount it when done if it was initially not
>  mounted.  This is the same thing that selinux_init_load_policy() does
>  when reading /proc/cmdline.
>
> If you think you know a better way, please provide a patch to upstream.

The thing is that I *don't* use SElinux, and this is why I see it as a
regression, and the main reason I don't really want to look at *another*
source tree for this. Maybe upstream is fixing this for distributions
that have a poor booting sequence. Incorrectly.

The patch might actually fix something if selinux is enabled, but
regresses in behavior for other scenarios where selinux is not used.

The fact that I was able to notice, you have to admit, is an indication
that there are cases where it is /not/ ok.

> I'll not carry a patch in debian and make libselinux behave differently
> than on 99% of the other distributions.

I, honestly, expected someone that understand the issue to help and
chime to report it upstream.

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

On Fri, May 13 2016, Laurent Bigonville  wrote:
> libselinux mounts /proc, check is the machine supports SELinux and then
> unmounts it. This is supposed to happen at early boot.

I don't understand what selinux is trying to solve here. It's not the
job of a library to mount filesystems. If you want to ensure that /proc
exists, mount it before.

The lazy unmount performed by selinuxfs_exists and
selinux_init_load_policy is racy.

Processes, run in parallel, *will* cause /proc to disappear right
between the mount call and the subsequent fopen call, so the code does
not function as upstream intends it to in any case.

> I would be interested to know what this behavior is breaking.

My main issue is within containers and chroots. I have my own
initialization process for these containers, I don't use selinux, but at
some point /proc gets mounted before I expect it to.

Even if the fix is simply the removal of the mountpoint, I consider the
solution broken by design.

> As I said on the other bugreport, please bring this upstream if you want
> this to change.

I'd like to know why, early at boot, this behavior is needed at all,
where it could be handled /without/ races.

For me this represents a regression in *all* binaries linked with
libselinux where selinux is disabled.

Bug#791662: aptitude: debdelta integration

[Yuri D'Elia]

On Thu, May 05 2016, Axel Beckert  wrote:
> What I do to use debdelta with aptitude, is the following:
>
> * Start "aptitude -u" inside a screen session
> * Wait until the package lists are updated.
> * Run "debdelta-upgrade" in a second window of the screen session
>   while aptitude's TUI is still open.
> * Any package scheduling change updates the amount of needed downloads
>   in the status line (top right).

Indeed, I do the same. Moreover, I generally specify manually the list
of packages to upgrade in debdelta-upgrade invocation (which is why I'd
like aptitude integration in the first place) to the same list I
selected in aptitude.

When having limited bandwidth, I have to hand-pick upgrades.

Bug#822692: [Pkg-phototools-devel] Bug#822692: Strange overscroll effect in settings

[Yuri D'Elia]

On Wed, May 04 2016, David Bremner  wrote:
> I've just uploaded 2.0.4-1, but I suspect your bug is still there. Or at
> least the scrolling looks a bit odd with gtk 3.20. If you can confirm
> the bug is still there for you in 2.0.4, I can open a ticket upstream.

The overscroll is still there, and still gray-on-gray.

It's actually more visible in the options -> presets (expand a few
items) and scroll.

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

Package: mount
Version: 2.28-1
Severity: important

Amusing, right? But not too much.

It does actually happen due to a new behavior in libselinux, which mount links 
against.
The same is true for any binary in util-linux and coreutils (and so on)

See bug #822679

I consider this behavior unexpected.
[and yes, I'm doing this to raise some awareness. Close the report if needed]

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

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

Versions of packages mount depends on:
ii  libblkid1  2.28-1
ii  libc6  2.22-7
ii  libmount1  2.28-1
ii  libselinux12.4-3+b1
ii  libsmartcols1  2.28-1
ii  libudev1   229-5

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

Bug#822679: [DSE-Dev] Bug#822679: closed by Laurent Bigonville <bi...@debian.org> (Bug#822679: fixed in libselinux 2.5-2)

[Yuri D'Elia]

On Sun, May 01 2016, Laurent Bigonville  wrote:
> It's only doing this if /proc is not mounted, something that should
> happen at early boot.
>
> libselinux needs to determine the status of selinux on the machine. This is 
> done by reading files
> under /proc.

libselinux should assume selinux is disabled if there's no proc, and
just do nothing.

Why the safe default cannot be followed here?
Can't "ls" just do it's work without policy until /proc is ready?

This is going to attempt mounting /proc in containers and generally mess
with event-based system initialization in unexpected ways.

I personally experienced this while setting up a testing environment
where selinux is _disabled_ and took me a while to track down why /proc
was getting mounted over and over again.

> If you want to change that, see with upstream.

Do I really have to?
This seems like a *very bad* idea in the first place.

Funny thing: unmount will now mount /proc.

Maybe I need to file a bugreport against mount.

Bug#822679: closed by Laurent Bigonville <bi...@debian.org> (Bug#822679: fixed in libselinux 2.5-2)

[Yuri D'Elia]

On Sun, May 01 2016, Debian Bug Tracking System  wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libselinux1 package:
>
> #822679: Attempts to mount /proc as a regular user

I'm _not_ happy with the solution here.

This will *still* cause regular userland utilities, such as ls on
Debian, to mount /proc when you least expect it to.

libselinux must just bail gracefully if /proc is not mounted.

Bug#822692: [Pkg-phototools-devel] Bug#822692: Strange overscroll effect in settings

[Yuri D'Elia]

On Wed, Apr 27 2016, David Bremner <da...@tethera.net> wrote:
> Yuri D'Elia <wav...@thregr.org> writes:
>
>> I personally wished darktable used the standard (system) GTK theme.
>> I'm not super-fond of the contrast and size of the visual elements.
>
> This seems unlikely to change any time soon. Since I don't use GTK
> themes myself, I'm not really the best person to understand the issues,
> but upstream seems quite attached to their visual style.

I know, and it's one of the reasons I used rawtherapee for quite some
time in the past. But I'm tired to squint just for some visual style. I
use themes to get consistency, and Darktable doesn't even respect the
system font size!

Oh well...

Bug#822692: [Pkg-phototools-devel] Bug#822692: Strange overscroll effect in settings

[Yuri D'Elia]

On Wed, Apr 27 2016, David Bremner  wrote:
> Hi Yuri;
>
> Thanks for the report. This annoyance, and several others, are due to
> changes in libgtk-3-0 3.20. The darktable team is working on a new point
> release that should fix these annoyances, hopefully sometime within the
> next week or so.

I personally wished darktable used the standard (system) GTK theme.
I'm not super-fond of the contrast and size of the visual elements.

Bug#822692: Strange overscroll effect in settings

[Yuri D'Elia]

Package: darktable
Version: 2.0.3-1+b2
Severity: minor

When I open the settings dialog and scroll the list with the wheel, there's
some sort of overscroll animation.

I have GTK animations turned off, so darktable shouldn't animate any dialog
elements in this case (no other gtk 3 list box does on my system).

On top of that, the overscroll effect is actually gray-on-gray (same
color of the list background), which just looked like a redrawing issue
and not an animation.

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

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

Versions of packages darktable depends on:
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-7
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libcolord-gtk10.1.26-1
ii  libcolord21.3.2-1
ii  libcups2  2.1.3-5
ii  libcurl3-gnutls   7.47.0-1
ii  libexiv2-14   0.25-2.1
ii  libflickcurl0 1.25-3
ii  libgcc1   1:6.0.1-2
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libgl1-mesa-glx [libgl1]  11.1.3-1
ii  libglib2.0-0  2.48.0-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgomp1  6.0.1-2
ii  libgphoto2-6  2.5.10-2
ii  libgphoto2-port12 2.5.10-2
ii  libgraphicsmagick-q16-3   1.3.23-2+b1
ii  libgtk-3-03.20.3-1
ii  libice6   2:1.0.9-1+b1
ii  libilmbase12  2.2.0-11
ii  libjpeg62-turbo   1:1.4.2-2
ii  libjs-prototype   1.7.1-3
ii  libjs-scriptaculous   1.9.0-2
ii  libjson-glib-1.0-01.2.0-1
ii  liblcms2-22.7-1
ii  liblensfun1   0.3.2-3
ii  liblua5.2-0   5.2.4-1
ii  libopenexr22  2.2.0-10
ii  libopenjpeg5  1:1.5.2-3.1
ii  libosmgpsmap-1.0-11.1.0-1
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpng16-16   1.6.21-4
ii  libpugixml1v5 1.7-2
ii  librsvg2-22.40.15-1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libsecret-1-0 0.18.5-1
ii  libsm62:1.2.2-1+b1
ii  libsoup2.4-1  2.54.0.1-2
ii  libsqlite3-0  3.12.2-1
ii  libstdc++66.0.1-2
ii  libtiff5  4.0.6-1
ii  libwebp5  0.4.4-1+b2
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.3+dfsg1-1
ii  libxrandr22:1.5.0-1
ii  zlib1g1:1.2.8.dfsg-2+b1

darktable recommends no packages.

darktable suggests no packages.

Bug#822679: Attempts to mount /proc as a regular user

[Yuri D'Elia]

Package: libselinux1
Version: 2.5-1
Severity: normal

I discovered after updating today libselinux1 that at every exec, each program
attempts to mount /proc, even if already mounted.

I'm looking at #789218, and still wonder... is it actually the job of
libselinux to mount filesystems?

My guess is that *no* user program should attempt to mount filesystems, EVER.
Moreso if the program in question has no rights to do so (ie, it's not root).

We attempt to mount /proc just to check /proc/filesystems?
Am I reading this right?

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

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

Versions of packages libselinux1 depends on:
ii  libc6 2.22-7
ii  libpcre3  2:8.38-3.1

libselinux1 recommends no packages.

libselinux1 suggests no packages.

Bug#822557: Please provide a python3 version

[Yuri D'Elia]

Package: python-cvxopt
Severity: wishlist

It would be nice if you could provide a python3-cvxopt package as well.
The upstream source is already compatibile with python 3.

Thanks.

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

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

Bug#822483: opencv-doc contains no documentation

[Yuri D'Elia]

Package: opencv-doc
Version: 2.4.9.1+dfsg-1.5
Severity: normal

I expected to find the actual documentation/reference in opencv-doc (as found
on docs.opencv.org), but it currently only contains the examples.

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

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

Bug#821291: Program received signal SIGSEGV, Segmentation fault.

[Yuri D'Elia]

Package: xpra
Version: 0.16.3+dfsg-1
Severity: normal

I cannot "attach" to a running xpra server. The client dies with a segmentation
fault:

% xpra attach 
2016-04-17 13:00:38,199 Error: printing disabled:

2016-04-17 13:00:38,199  No module named cups
2016-04-17 13:00:38,219 Xpra gtk2 client version 0.16.3-r12205
2016-04-17 13:00:38,219  running on Linux debian stretch/sid
2016-04-17 13:00:38,404 GStreamer version 1.8 for Python 2.7
2016-04-17 13:00:38,647 PyOpenGL warning: missing accelerate module
2016-04-17 13:00:38,647 PyOpenGL warning: missing array format handlers: 
numeric, vbo, vbooffset
2016-04-17 13:00:38,647 OpenGL Version: 3.0 Mesa 11.1.2
2016-04-17 13:00:38,649 OpenGL support is missing:
2016-04-17 13:00:38,649  PyOpenGL version 3.1 or later is required (found 
version 3.0.2)
2016-04-17 13:00:38,904  detected keyboard: rules=evdev, model=pc105, layout=us
2016-04-17 13:00:38,905  desktop size is 4480x1440 with 1 screen:
2016-04-17 13:00:38,905   :0.0 (1197x385 mm - DPI: 95x95)
2016-04-17 13:00:38,905 monitor 1 1920x1200 (518x324 mm - DPI: 94x94)
2016-04-17 13:00:38,905 monitor 2 2560x1440 at 1920x0 (310x174 mm - DPI: 
209x210)
2016-04-17 13:00:38,906  upscaled by 125%, virtual screen size: 3584x1152
2016-04-17 13:00:38,906   :0.0 (1197x385 mm - DPI: 76x76)
2016-04-17 13:00:38,906 monitor 1 1536x960 (518x324 mm - DPI: 75x75)
2016-04-17 13:00:38,906 monitor 2 2048x1152 at 1536x0 (310x174 mm - DPI: 
167x168)
sh: segmentation fault  xpra attach

I tried to disable pretty much any extension (gstreamer, sound, GL printing) to 
no avail.
The crash itself is located in glib:

Program received signal SIGSEGV, Segmentation fault.
0x720406f0 in g_str_hash () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0x720406f0 in g_str_hash () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7203f35b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fffed114da8 in gtk_icon_theme_list_contexts () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#3  0x7fffed745448 in ?? () from 
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/_gtk.so

I cannot seem to get a working gdb with python 2 right now (gdb-python2 is
actually linked with python3), so I cannot provide a python stack trace.

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

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

Versions of packages xpra depends on:
ii  adduser3.114
ii  libavcodec-ffmpeg-extra56  7:2.8.6-1+b2
ii  libavutil-ffmpeg54 7:2.8.6-1+b2
ii  libc6  2.22-6
ii  libgtk2.0-02.24.30-1.1
ii  libswscale-ffmpeg3 7:2.8.6-1+b2
ii  libvpx31.5.0-2
ii  libwebp5   0.4.4-1+b2
ii  libx11-6   2:1.6.3-1
ii  libx264-1482:0.148.2643+git5c65704-1
ii  libxcomposite1 1:0.4.4-1
ii  libxdamage11:1.1.4-2+b1
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.1-2+b2
ii  libxkbfile11:1.0.9-2
ii  libxrandr2 2:1.5.0-1
ii  libxtst6   2:1.2.2-1+b1
ii  python 2.7.11-1
ii  python-gi-cairo3.18.2-2+b1
ii  python-gtk22.24.0-4
ii  python-rencode 1.0.4-1
pn  python:any 
ii  x11-xserver-utils  7.7+7
ii  xserver-xorg-input-void1:1.4.1-1+b1
ii  xserver-xorg-video-dummy   1:0.3.7-1+b5

Versions of packages xpra recommends:
ii  keyboard-configuration  1.141
ii  openssh-client  1:7.2p2-4
ii  python-dbus 1.2.4-1
ii  python-gtkglext11.1.0-9.1
ii  python-lz4  0.7.0+dfsg-3+b2
ii  python-lzo  1.08-1
ii  python-pil  3.2.0-1
pn  ssh-askpass 

Versions of packages xpra suggests:
ii  cups-common 2.1.3-5
ii  cups-filters1.8.3-2+b1
ii  gstreamer1.0-plugins-base   1.8.0-1
ii  gstreamer1.0-plugins-good   1.8.0-1+b1
ii  openssh-server  1:7.2p2-4
ii  printer-driver-cups-pdf [cups-pdf]  2.6.1-21
pn  pulseaudio  
pn  pulseaudio-utils
pn  python-avahi
pn  python-cups 
ii  python-gst-1.0  1.8.0-1
pn  python-netifaces
pn  python-pyopencl 
ii  python-yaml 3.11-3+b1

Bug#820870: Error when installing emacs24 elisp files

[Yuri D'Elia]

Package: gforth
Version: 0.7.3+dfsg-2
Severity: normal

Setting up gforth (0.7.3+dfsg-2) ...
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install gforth for emacs24
install/gforth: Handling install for emacsen flavor emacs24

Error occurred processing *.el: File error (("Opening input file" "no such file or 
directory" "/usr/share/emacs24/site-lisp/gforth/*.el"))

Wrote /usr/share/emacs24/site-lisp/gforth/path.elc
ERROR: install script from gforth package failed
dpkg: error processing package gforth (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
gforth
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up gforth (0.7.3+dfsg-2) ...
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install gforth for emacs24
install/gforth: Handling install for emacsen flavor emacs24

Error occurred processing *.el: File error (("Opening input file" "no such file or 
directory" "/usr/share/emacs24/site-lisp/gforth/*.el"))

Wrote /usr/share/emacs24/site-lisp/gforth/path.elc
ERROR: install script from gforth package failed
dpkg: error processing package gforth (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
gforth

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

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

Versions of packages gforth depends on:
ii  emacsen-common  2.0.8
ii  gforth-common   0.7.3+dfsg-2
ii  gforth-lib  0.7.3+dfsg-2
ii  libc6   2.22-6
ii  libffi6 3.2.1-4
ii  libltdl72.4.6-0.1

gforth recommends no packages.

gforth suggests no packages.

Bug#819239: FUSE + linger = stuck shutdown at unmount

[Yuri D'Elia]

Package: systemd
Version: 229-3
Severity: normal

I've been having problems at shutdown since I've switched to systemd, but due
to the inability of debugging systemd during shutdown it's a bit tricky to know
exactly what's going on. I apologize in advance for not having fully debugged
this, but I need some assistance.

I'm using sshfs in combination with user lingering. When I initiate a shutdown,
it generally gets stuck while unmounting /home because it's busy.

I realized this only happens when I had an active sshfs mount. Since I have
user lingering enabled, I assume sshfs itself is not killed when the session is
closed.

I have a couple of questions:

- Does systemd try to unmount FUSE filesystems at shutdown? (Should it try at 
all?)

 Please note that in this case, sshfs requires the network to shutdown
 correctly, so it might be that it's being unmounted after the network is not
 available anymore, causing unmount to get stuck anyway.

- Does systemd still try to kill all remaining user processes before unmounting?

 This used to be a step in sysv-init in order to release all filesystems
 before unmounting. In theory, user processes are released when stopping the
 user session, but this is not true when user lingering is enabled. You might
 still need to kill pending user processes before unmounting.

Thanks.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.114
ii  libacl1 2.2.52-3
ii  libapparmor12.10-3+b1
ii  libaudit1   1:2.4.5-1+b1
ii  libblkid1   2.27.1-6
ii  libc6   2.22-4
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.6.5-2
ii  libgpg-error0   1.21-2
ii  libkmod222-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-6
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.2.3-3
ii  libselinux1 2.4-3+b1
ii  libsystemd0 229-3
ii  mount   2.27.1-6
ii  util-linux  2.27.1-6

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  229-3

Versions of packages systemd suggests:
ii  systemd-container  229-3
ii  systemd-ui 3-4

Versions of packages systemd is related to:
ii  udev  229-3

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/resolved.conf changed [not included]
/etc/systemd/timesyncd.conf changed [not included]

Bug#819114: Job reported as failed, but wasn't

[Yuri D'Elia]

Package: systemd-cron
Version: 1.5.4-1
Severity: normal

I've added a cronjob that runs as my user every minute (fetchmail).
Occasionally, the job is reported as failed with the following email:

Subject: [laptop] job cron-wavexx-wavexx-0 failed

● cron-wavexx-wavexx-0.service - [Cron] "* * * * * fetchmail"
  Loaded: loaded (/var/spool/cron/crontabs/wavexx; bad; vendor preset: enabled)
  Active: inactive (dead) since Wed 2016-03-23 18:40:14 CET; 36ms ago
Docs: man:systemd-crontab-generator(8)
 Process: 30246 ExecStart=/usr/bin/zsh -c fetchmail (code=exited, 
status=0/SUCCESS)
Main PID: 30246 (code=exited, status=0/SUCCESS)

Mar 23 18:40:14 eab16011nb systemd[1]: Starting [Cron] "* * * * * fetchmail"...
Mar 23 18:40:14 eab16011nb systemd[1]: Started [Cron] "* * * * * fetchmail".

So it exited with code 0. What exactly has failed here?

-- Package-specific info:
-- output of systemd-delta

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

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

Versions of packages systemd-cron depends on:
ii  init-system-helpers  1.29
ii  libc62.22-4
pn  python3:any  
ii  systemd-sysv 229-3

Versions of packages systemd-cron recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.86.2-2

systemd-cron suggests no packages.

Bug#743215: write: you are uid ???, but your login is as uid 0

[Yuri D'Elia]

On Sat, Mar 19 2016, Michael Meskes  wrote:
> This is my second and last try. Could one of you please, pretty please,
> describe the bug and explain what does not work although it should, ideally in
> a way that makes it possible for me to reproduce it? So far, this bug report
> has nothing to work with.

If you did ask before, I didn't receive anything.

But anyway, it's easy. To get exactly the same behavior, on sid, login
as root. Then:

sudo -u user write user

Where "user" is any username of a valid, logged-in account with messages
enabled.

Do you agree here, that write shouldn't prevent me to write to myself in
this case? Pretty obvious.

Where this behavior actually happens you ask? I want to notify myself
when running in a cron job. Or at completion of scripts in batch
scripts, or job schedulers, or anything that changes username for any
reason whatsoever.

If I didn't want messages, I would turn them off (which is the default
anyway).

Now, the bigger picture is that the check itself is bogus.
Write shouldn't care about the original uid at all. What exactly is this
check preventing?

I hope this is clear now.

Bug#817922: [Pkg-roundcube-maintainers] Bug#817922: PEAR issues

[Yuri D'Elia]

On Fri, Mar 18 2016, Sandro Knauß  wrote:
>> That silenced fatal error is only one of at least two I found attempting
>> to call PEAR. Incredibly frustrating.
>
> I see - Do you have a patch for makeing it more verbosy?

I'm not sure about the reasoning of the silencing, but I didn't have
time to investigate.

I suspect that these are calls that might used to produce noise, or were
expected to emit warnings and now produce a fatal error (just grep for
all instances of @PEAR).

>> Apart for some minor session issues (session_renegerate_id failing
>> somewhere due to the sqlite3 backend), I was able to make it run with
>> PHP7 (albeit with several deprecation warnings).
>>
>> Looks like it's not too far off for php 7.
>
> So you haven't to change anything on the code to get it running with php7?

Unfortunately, I had to, but nothing major really. The issue with
session_regenerate_id is nested in some change of semantics in session
cleanup inside the sqlite3 session handler, but that needs to be fixed
properly and I don't want to suggest to comment it out.

I'd expect RC to work without much hassle on both php 5.x and 7.

The biggest hurdle I see is the pear transition though.

Bug#817922: [Pkg-roundcube-maintainers] Bug#817922: PEAR issues

[Yuri D'Elia]

On Sun, Mar 13 2016, Sandro Knauß  wrote:
> The PHP team is currently running a transistion to PHP7, that's why all
> packages are recompiled against PHP7 [0]. On the other side roundcube is
> currently not working with PHP7 and the pear packages built against PHP5 are
> removed from the repository . Roundcube has released a first 1.2-beta with 
> PHP7
> support [1] but this will take some month till the the version is released.

Note that I also couldn't make it run correctly with php5-fpm and taking
php-pear from testing (which is still for 5.x). Somehow RC itself
introduced some breaking change I couldn't track down.

That silenced fatal error is only one of at least two I found attempting
to call PEAR. Incredibly frustrating.

> So the only solution is to run roundcube with PHP 7 and create a patch for
> that. Maybe it is enough to backport the related patches to ticket 1490416
> [2]. For me it is out of scope currently do that.

Apart for some minor session issues (session_renegerate_id failing
somewhere due to the sqlite3 backend), I was able to make it run with
PHP7 (albeit with several deprecation warnings).

Looks like it's not too far off for php 7.

But I'd suggest, if you have the time, to check if this version of RC
still runs at all with php5 in testing.

Bug#817922: PEAR issues

[Yuri D'Elia]

Source: roundcube
Severity: important

I'm trying to install roundcube from stratch on sid along with php5-fpm, but it
fails silently with an internal error.

The error is caused in a silenced call to PEAR::setErrorHandling
(/usr/share/roundcube/program/lib/Roundcube/bootstrap.php:102). The error is
fatal though. It shouldn't be silenced!

The current php-pear (1.10.1.*) requires php 7, so I assume pear now only works
properly with PHP 7?

But roundcube-core explicitly depends on php5 packages (php5-cli, etc). Does
roundcube-core work correctly with php 7? If so, package dependencies should be
updated.

It seems that the current combination cannot possibly work.

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

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

Bug#817792: Unavailable dependencies on unstable

[Yuri D'Elia]

Package: roundcube-core
Severity: normal

The current dependencies on php-net-idna2/php-mail-mime/etc make this package
currently uninstallable on unstable.

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

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

Bug#816690: Thinkpad Carbon X1: RIP [] unlink_anon_vmas+0x4f/0x1a0

[Yuri D'Elia]

Package: src:linux
Version: 4.4.2-3
Severity: normal

I'm having some strange problems with the 4.4.2-3 kernel in
high-load/high-memory-pressure situations with a ThinkPad Carbon X1 (3rd gen)
laptop, with a fault in unlink_anon_vmas.

It tends to hang right after turning on my monitor (which I'm also using with
as an USB hub), or when waking up the monitor from DPMS which causes the hub to
start working again. But I have no clue if it is related really, as I couldn't
reproduce the issue at all under low load situations.

In the log (which is short enough), it starts at the 8242.569150 mark.

I was able to trigger this issue three times in a couple of hours, while
reading intensively from the disk.

Please let me know if there's anything I can do to help.


-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160205 (Debian 5.3.1-8) ) #1 SMP Debian 4.4.2-3 (2016-02-21)

** Command line:
BOOT_IMAGE=/vmlinuz-4.4.0-1-amd64 root=/dev/mapper/vg-root ro

** Tainted: DWO (4736)
* Kernel has oopsed before.
* Taint on warning.
* Out-of-tree module has been loaded.

** Kernel log:
[   16.249113] iTCO_wdt: Found a Wildcat Point_LP TCO device (Version=2, 
TCOBASE=0x1860)
[   16.249308] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   16.419460] Bluetooth: Core ver 2.21
[   16.419593] NET: Registered protocol family 31
[   16.419594] Bluetooth: HCI device and connection manager initialized
[   16.419597] Bluetooth: HCI socket layer initialized
[   16.419599] Bluetooth: L2CAP socket layer initialized
[   16.419605] Bluetooth: SCO socket layer initialized
[   16.423548] usbcore: registered new interface driver btusb
[   16.930908] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb2/2-5/2-5:1.0/0003:04F3:012D.0001/input/input19
[   16.931029] hid-multitouch 0003:04F3:012D.0001: input,hiddev0,hidraw3: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-5/input0
[   16.963172] media: Linux media interface: v0.10
[   16.966492] Linux video capture interface: v2.00
[   17.053611] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b45d)
[   17.056468] input: Integrated Camera as 
/devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/input/input21
[   17.056531] usbcore: registered new interface driver uvcvideo
[   17.056531] USB Video Class driver (1.1.1)
[   17.538575] Console: switching to colour frame buffer device 240x75
[   17.543844] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   17.573459] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   17.578934] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[   17.688840] usb 2-2.3.3: USB disconnect, device number 10
[   17.779629] cgroup: new mount options do not match the existing superblock, 
will be ignored
[   17.848586] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
[   17.853276] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
[   17.923935] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
[   17.927543] iwlwifi :04:00.0: L1 Enabled - LTR Enabled
[   17.956838] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   17.977566] Process accounting resumed
[   18.013330] ip_tables: (C) 2000-2006 Netfilter Core Team
[   18.165424] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   18.176129] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[   18.203345] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   18.379187] snd_hda_codec_hdmi hdaudioC1D0: HDMI: ELD buf size is 0, force 
128
[   18.381061] snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid ELD data byte 0
[   21.790888] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 
None
[   21.790919] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.495795] fuse init (API version 7.23)
[ 2134.406442] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[ 2134.409747] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[ 3985.207166] usb 2-2.3.3: new high-speed USB device number 11 using xhci_hcd
[ 3985.391000] usb 2-2.3.3: New USB device found, idVendor=0bda, idProduct=0307
[ 3985.391004] usb 2-2.3.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 3985.391006] usb 2-2.3.3: Product: USB3.0 Card Reader
[ 3985.391007] usb 2-2.3.3: Manufacturer: Realtek
[ 3985.391008] usb 2-2.3.3: SerialNumber: F131C0013FE5
[ 3985.396559] usb-storage 2-2.3.3:1.0: USB Mass Storage device detected
[ 3985.396697] scsi host5: usb-storage 2-2.3.3:1.0
[ 3986.401275] scsi 5:0:0:0: Direct-Access Generic- SD/MMC/MS/MSPRO  1.00 
PQ: 0 ANSI: 4
[ 3986.401630] sd 5:0:0:0: Attached scsi generic sg1 type 0
[ 3986.407688] sd 5:0:0:0: [sdb] Attached SCSI removable disk
[ 4696.411483] usb 2-2.3.3: USB disconnect, device number 11
[ 8242.569150] usb 2-2.3.3: new high-speed USB device number 12 using xhci_hcd
[ 8242.753343] usb 2-2.3.3: New USB device found, idVendor=0bda, idProduct=0307
[ 8242.753348] usb 2-2.3.3: New USB device strings: Mfr=1, 

Bug#816550: Should Suggest: org-mode-doc

[Yuri D'Elia]

Package: org-mode
Version: 8.3.3-3
Severity: wishlist

It would be nice if org-mode would suggest its own documentation.
Thanks.

Bug#816547: Resets the logfile permissions at each invocation

[Yuri D'Elia]

Package: udevil
Version: 0.4.4-1
Severity: normal

I want to log every use of udevil, and I'm trying to use logrotate to handle 
the log as well.
For this reason I have the following set in udevil.conf:

log_file = /var/log/udevil.log
log_keep_days = 0

By default, udevil creates the logfile with root:[group of the invoking user] 
with mode 0700.
The mode is also reset at each invocation.

This is doubly wrong: permissions should be 600 at best.
If the file already exists, existing mode and permissions *must* be kept.

Looking at udevil.c:dump_log, I would argue that the chmod() call at the end
should be removed in favor of a strict umask before the fopen() call. This
avoids the current race that the logfile might have different permissions while
it's being written.

On a side note, the idea that udevil itself would expire individual entries by
re-reading its entried from the text file is troubling. I would argue that this
should never be done in udevil itself, and the (commented) default of
log_keep_days in be set to 0.

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

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

Versions of packages udevil depends on:
ii  libc6 2.21-9
ii  libglib2.0-0  2.46.2-3
ii  libudev1  229-2

Versions of packages udevil recommends:
pn  pmount   
pn  udisks2  
pn  zenity   

Versions of packages udevil suggests:
pn  cifs-utils  
ii  curlftpfs   0.9.2-9
pn  eject   
ii  sshfs   2.5-1

-- Configuration Files:
/etc/udevil/udevil.conf changed [not included]

Bug#816497: aptitude: problems with (un)markauto

[Yuri D'Elia]

Package: aptitude
Followup-For: Bug #816497

Auto flags seem to be totally broken.

I can mark a package for manual installation (vbetool), and just after the
installation the package is marked as automatically installed and for removal.

On the other side, aptitude-common was switched from automatically installed to
manually installed for no reason.

In fact, by cursory looking, looks like flags for *many* packages got flipped
at random!

-- Package-specific info:
Terminal: linux
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.7
Compiler: g++ 5.3.1 20160224
Compiled against:
 apt version 5.0.0
 NCurses version 6.0
 libsigc++ version: 2.6.2
 Gtk+ support disabled.
 Qt support disabled.

Current library versions:
 NCurses version: ncurses 6.0.20160213
 cwidget version: 0.5.17
 Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffda0905000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7fddfb9a1000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fddfb771000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fddfb546000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fddfb34)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fddfb043000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fddfad6c000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7fddfab52000)
libboost_filesystem.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7fddfa939000)
libboost_system.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7fddfa734000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7fddfa33)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fddfa113000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fddf9d8f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fddf9a8a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fddf9874000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fddf94cf000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fddf92cc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fddf90c8000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fddf8eb)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fddf8c95000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fddf8a85000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fddf8861000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fddf864f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fddf8446000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fddf8241000)
/lib64/ld-linux-x86-64.so.2 (0x55c6ddaaf000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.7.7-1
ii  libapt-pkg5.0  1.2.4
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5+b1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5+b1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.21-9
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6-20160228-1
ii  libncursesw5   6.0+20160213-1
ii  libsigc++-2.0-0v5  2.6.2-1
ii  libsqlite3-0   3.11.0-2
ii  libstdc++6 6-20160228-1
ii  libtinfo5  6.0+20160213-1
ii  libxapian22v5  1.2.22-3

Versions of packages aptitude recommends:
pn  aptitude-doc-en | aptitude-doc  
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47+nmu2
ii  debtags   2.0.2
pn  tasksel   

Bug#816304: Drop dependency on liblouis-data

[Yuri D'Elia]

Package: cups-filters
Version: 1.8.2-2
Severity: minor

Logging this here before it gets forgotten.

After bug #813094 was fixed, there's no reason to depend on liblouis-data 
itself.
It can be dropped as well.

Thanks.

Bug#816111: Larger font variants for HiDPI displays

[Yuri D'Elia]

Package: console-setup
Version: 1.137
Severity: wishlist

With a display close to 300dpi and the proper KMS driver, the framebuffer
effectively becomes HiDPI as well.

The largest font currently available in console-setup is 16x32 pixels, which
might not be big enough to be read confortably anymore.

Having some extra intermediate sizes up to 32x64 might be helpful, without
having to resort to lowering the resolution and incurring in switching between
X11 and the console.

It's a bit sad terminus doesn't include higher sizes, but rasterizing any
monospace TT font with good hinting such a DejaVu Sans Mono at this resolution
should give pretty good results.

Bug#816095: Enable HTTP/2 in nginx-light

[Yuri D'Elia]

Package: nginx-light
Severity: wishlist

I was looking for a small HTTP/2 server that has at least fastcgi and rewriting
support.

nginx-light fits the bill (there aren't alternatives really[!]), except HTTP/2
is included only in -full.

Would it be possible to include HTTP/2 also in light?
I believe HTTP/2 fits the "light" concept ;)

Bug#759657: console-setup w/ systemd forgets font setting

[Yuri D'Elia]

Package: console-setup
Version: 1.137
Followup-For: Bug #759657

I've just experienced this bug. I've installed a fresh debian system on a new 
laptop (using sid) from scratch.

I've configured console-setup to use TerminusBold 16x32, and while it works 
just after running dpkg-reconfigure, the setting is not correctly restored 
after a reboot.
Due to the high resolution of the screen in this laptop, I cannot actually read 
anything without.

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

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

Versions of packages console-setup depends on:
ii  console-setup-linux 1.137
ii  debconf 1.5.58
ii  keyboard-configuration  1.137
ii  xkb-data2.17-1

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.21-9
ii  lsb-base  9.20160110

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.58
ii  initscripts 2.88dsf-59.3
ii  liblocale-gettext-perl  1.07-1+b1

Versions of packages console-setup-linux depends on:
ii  kbd 2.0.3-2
ii  keyboard-configuration  1.137

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2

Bug#814907: php5-fpm.service: Got notification message from PID X, but reception only permitted for main PID Y

[Yuri D'Elia]

Package: php5-fpm
Severity: minor

I started to see this message in the syslog from php5-fpm recently.
This looks the same instance as bug #809035:

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

which involves sd_notify() with forked processes.

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

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

Bug#813094: Split braille support into a separate package

[Yuri D'Elia]

On Sun, Feb 14 2016, Till Kamppeter  wrote:
> I think this is a good idea. It makes one of the two utility packages be
> installed if at least one is available (ex: Ubuntu with only Main) and
> does not error if none is available. And it prefers the better if both
> are available (Debian and Ubuntu with Main and Universe).
>
> Let us go this way.

The liblouis-data dependency should be removed completely now.
It's automatically pulled by the liblouis libraries.

Bug#814810: Explicit dependency on g++/g++-5

[Yuri D'Elia]

Package: libboost-dev
Version: 1.58.0.1
Severity: minor

libboost-dev (and libboost-*-dev packages) explicitly depend on g++/g++-5.
Is this explicity (double) dependency necessary?

The individual packages already depend on libstdc++-5-dev, which is the correct
thing to do.

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

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

Versions of packages libboost-dev depends on:
ii  g++   4:6-20160101-2
ii  g++-5 5.3.1-8
ii  libboost1.58-dev  1.58.0+dfsg-5+b1
ii  libstdc++-5-dev   5.3.1-8

libboost-dev recommends no packages.

Versions of packages libboost-dev suggests:
ii  libboost-doc  1.58.0.1

Bug#814808: libboost-doc depends on g++/g++-5

[Yuri D'Elia]

Package: libboost-doc
Version: 1.58.0.1
Severity: minor

There's no reason for libboost-doc to depend on g++ and g++-5.

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

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

Versions of packages libboost-doc depends on:
ii  g++   4:6-20160101-2
ii  g++-5 5.3.1-8
ii  libboost1.58-doc  1.58.0+dfsg-5
ii  libstdc++-5-dev   5.3.1-8

libboost-doc recommends no packages.

libboost-doc suggests no packages.

Bug#814024: Reduce dependencies (on tcl/tk?)

[Yuri D'Elia]

Package: python3-matplotlib
Version: 1.5.1~rc1-1
Severity: wishlist

I recently needed to produce some plots in a headless environment (using the
agg backend), but realized that the current dependencies are quite hefty.

Not too unexpected, but by looking carefully I noticed that python3-matplotlib
is already *much* better than python-matplotlib in this regard. It still
depends on libtcl8.6/libtk8.6 though, which will pull x11 as a result.

Is this dependency strictly necessary for matplotlib to work with the agg
backend? Is it possible, maybe through some work, to demote it to a recommends?

Bug#813929: Should Suggest: openmpi-doc

[Yuri D'Elia]

Package: libopenmpi-dev
Version: 1.10.2-4
Severity: minor

It would be nice if libopenmpi-dev would suggest it's own documentation.
Thanks.

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

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

Versions of packages libopenmpi-dev depends on:
ii  libc6   2.21-7
ii  libhwloc-dev1.11.2-2
ii  libhwloc5   1.11.2-2
ii  libibverbs-dev  1.1.8-1.1
ii  libopenmpi1.10  1.10.2-4
ii  openmpi-common  1.10.2-4

libopenmpi-dev recommends no packages.

libopenmpi-dev suggests no packages.

Bug#809323: systemd-rfkill.socket doesn't load at startup

[Yuri D'Elia]

On 03/02/16 03:52, Michael Biebl wrote:
>> Dec 03 00:25:48 eab14156nb systemd[1]: systemd-rfkill.socket: Socket service 
>> systemd-rfkill.service not loaded, refusing.
>> Dec 03 00:25:48 eab14156nb systemd[1]: Failed to listen on Load/Save RF Kill 
>> Switch Status /dev/rfkill Watch.
>>
>> Shouldn't it Depend/After explictly systemd-rfkill.service?
> 
> What's the output of
> systemctl status systemd-rfkill.service
> systemctl status systemd-rfkill.socket
> 
> Booking with systemd.log_level=debug on the kernel command line and
> attaching the output of journalctl -alb might be helpful as well when
> that problem happens.

That would basically mean booting with log_level=debug from now on and
waiting for this to happen again. Might not be instantaneous.

Can I ask in advance what kind of issue are you expecting to see?




signature.asc
Description: OpenPGP digital signature

Bug#813094: Split braille support into a separate package

[Yuri D'Elia]

On 01/02/16 11:58, Samuel Thibault wrote:
>> The double recommend/suggests is a bit wonky.
>> Maybe you should recommend on (liblouis-bin | liblouisutdml-bin).
>>
>> I don't know what's the difference in braille support between
>> liblouis-bin and liblouisutdml-bin, but if the package is recommended I
>> would go for the better one only.
> 
> The better one is liblouisutdml-bin, which provides better document
> parsing than the basic liblouis-bin.
> 
> The issue is that ubuntu does not have liblouisutdml-bin in main, only
> in universe.

Ah, I see now.
Then I would simply recommend on (liblouisutdml-bin | liblouis-bin).

Bug#813094: Split braille support into a separate package

[Yuri D'Elia]

On 01/02/16 09:14, Samuel Thibault wrote:
>> On top of that, since scripts themselves can probe if louis is not available,
>> there's no need for the dependency and fallback mechanism: just
>> probe for liblouisutdml-bin directly, or quit otherwise.
> 
> We could lower the liblouis-bin dependency to a Recommends only indeed,
> so that it gets pulled by default, but not made mandatory.

The double recommend/suggests is a bit wonky.
Maybe you should recommend on (liblouis-bin | liblouisutdml-bin).

I don't know what's the difference in braille support between
liblouis-bin and liblouisutdml-bin, but if the package is recommended I
would go for the better one only.

Bug#813195: RFP: kaptain -- universal graphical front-end for command line programs

[Yuri D'Elia]

Package: wnpp
Severity: wishlist

* Package name: kaptain
  Version : 0.73
  Upstream Author : Zsolt Terek 
* URL : http://kaptain.sourceforge.net/
* License : GPL
  Programming Lang: C++
  Description : universal graphical front-end for command line programs

Kaptain is a universal graphical front-end for command line programs. It works
on linux/UNIX platforms whereever Qt is available.

Someone writes a simple script (so called grammar) which describes the possible
arguments for a command line program and Kaptain brings up a friendly dialog to
the user to set up the command line. 

Bug#813094: Split braille support into a separate package

[Yuri D'Elia]

Package: cups-filters
Version: 1.8.1-1
Severity: whishlist

This is a followup of #808057. In the previous bug, the dependency on
liblouisutdml-bin has been demoted to a suggests, but the package now depends
on liblouis-bin and liblouis-data, with still ~7mb of additional dependencies.

It would be nice if you could split off braille support into a separate
package, as originally mentioned in #808057. cups-filters is a depenency of
cups itself, so it would be nice if we could keep that small for print servers.

On top of that, since scripts themselves can probe if louis is not available,
there's no need for the dependency and fallback mechanism: just
probe for liblouisutdml-bin directly, or quit otherwise.

Systems that don't have braille support have no use for liblouis-bin either,
while people that need braille will probably have to look for the full package.
I do not think that the current status is a good solution.

Bug#812583: Could use vmdebootstrap

[Yuri D'Elia]

Package: qemubuilder
Version: 0.78
Severity: wishlist

I'm not sure if this is technically sound, but would it make sense to use
vmdebootstrap to setup the virtual image as needed by qemubuilder instead of
wrapping debootstrap manually?

I'm trying to use the same process/image for both qemubuilder and autopkgtest,
but while it looks like there's a lot of overlap, there's really no integration
on that front.

Bug#812581: qemu complains about missing image format

[Yuri D'Elia]

Package: qemubuilder
Version: 0.78
Severity: minor

The following warnings are visible when qemu/kvm is started:

  forking qemu: kvm -nodefaults -nographic -M pc -m 1024 -kernel 
/var/cache/pbuilder/kernel/debian-live-8.2.0-amd64-standard.vmlinuz -initrd 
/var/cache/pbuilder/kernel/debian-live-8.2.0-amd64-standard.initrd.img -drive 
file=/var/cache/pbuilder/base.qemu,index=0,media=disk,cache=writeback,id=hd0 
-drive 
file=/var/cache/pbuilder/build/qemu.29814.dev,index=1,media=disk,cache=writeback,id=hd1
 -append root=/dev/sda quiet init=/pbuilder-run console=ttyS0,115200n8 -serial 
stdio -net user -net nic 
WARNING: Image format was not specified for '/var/cache/pbuilder/base.qemu' and 
probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
WARNING: Image format was not specified for 
'/var/cache/pbuilder/build/qemu.29814.dev' and probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.

Bug#812584: Support lxc-based build environment

[Yuri D'Elia]

Package: pbuilder
Version: 0.222
Severity: wishlist

lxc-based containers with an overlay image would be a superior replacement to
chroot-based images, and would make cowbuilder basically obsolete.

In fact, autopkgtest has support for lxc containers as well, and it would be
nice if we could share (in one way or the other) the same base container for
both building and testing a package.

Bug#808057: marked as done (Please demote dependency on liblouisutdm1-bin)

[Yuri D'Elia]

On 22/01/16 10:54, Debian Bug Tracking System wrote:
>[ Till Kamppeter ]
>* Let cups-drivers not depend on liblouisutdml-bin any more, instead, let 
> it
>  depend on liblouis-bin and move liblouisutdml-bin to Suggests
>  (Closes: #808057)

This still pulls ~7mb of additional dependencies though. I'm not too
happy about it, since I'm space-constrained on a few print servers I
have and that's additional spooling space being lost.

Since I assume liblouis-bin is just called/probed through exec, there's
no real reason to depend on it (or there is?). Couldn't you just
suggest/recommend liblouisutmdl-bin directly and avoid using a fallback
entirely?

I'm fine with the filter failing, since I cannot read/write/print
braille anyway. And likewise I assume that people that need braille want
the full package.

Bug#808057: Please demote dependency on liblouisutdm1-bin

[Yuri D'Elia]

Package: cups-filters
Version: 1.7.0-1
Followup-For: Bug #808057

Hi, I've seen this discussed for 1.4.*, but cups-filters is now at 1.7 and
liblouis-data/liblouisutdml-bin are still hard dependencies.

Bug#811294: ITP: tabview -- curses command-line CSV and list (tabular data) viewer

[Yuri D'Elia]

Package: wnpp
Severity: wishlist
Owner: "Yuri D'Elia" <wav...@thregr.org>

* Package name: tabview
  Version : 1.4.1
  Upstream Author : Scott Hansen <firecat4...@gmail.com>
* URL : https://github.com/firecat53/tabview
* License : MIT
  Programming Lang: Python
  Description : curses command-line CSV and list (tabular data) viewer

tabview is both a minimal, stand-alone curses command-line CSV/tabular-data
viewer and a Python module that can be used to view basic Python types directly
in an interactive spreadsheet.

The curses interface offers VIM-like keyboard bindings, sorting and full-text
incremental search.

---

There are currently very few alternatives to tabview in debian. I've used "sc"
and "teapot" (not in Debian) to the same extent, however both are complete
spreadsheet programs (with sc requiring an extra "import" step), whereas
tabview allows to just view a csv/tsv file easily.

tabview is both helpful stand-alone, but also works greatly when used in
combination with ipython or any interactive python session, allowing one to
browse through a large data table visually. To this extent, I'm using tabview
heavily with the scipy stack.

I'm planning to maintain this package in the python-modules team.

Bug#811299: ITP: gtabview -- simple graphical tabular data viewer

[Yuri D'Elia]

Package: wnpp
Severity: wishlist
Owner: "Yuri D'Elia" <wav...@thregr.org>

* Package name: gtabview
  Version : 0.6
  Upstream Author : Yuri D'Elia <wav...@thregr.org>
* URL : https://github.com/wavexx/gtabview
* License : MIT
  Programming Lang: Python
  Description : simple graphical tabular data viewer

Simple graphical tabular data viewer that can be used both stand-alone and as a
Python module for various files and Python/Pandas/NumPy data structures.

---

There are currently very few alternatives to gtabview in debian. I've used "sc"
and "teapot" (not in Debian) to the same extent, however both are complete
spreadsheet programs (with sc requiring an extra "import" step), whereas
gtabview allows to just view a tabular text file easily.

I'm also packaging "tabview" (see ITP #811294), which is the curses analogue.

gtabview is both helpful stand-alone, but also works greatly when used in
combination with ipython or any interactive python session, allowing one to
browse through a large data table visually. To this extent, I'm using gtabview
heavily within emacs and the scipy stack.

I'm planning to maintain this package in the python-modules team.

Bug#810543: RFS: python-bond/1.4-1 [ITP]

[Yuri D'Elia]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-bond"

* Package name: python-bond
  Version : 1.4-1
  Upstream Author : Yuri D'Elia <wav...@thregr.org>
* URL : http://www.thregr.org/~wavexx/software/python-bond/
* License : GPL-2+
  Section : python

It builds those binary packages:

python-bond - transparent remote/recursive evaluation between Python and other 
languages
python3-bond - transparent remote/recursive evaluation between Python and other 
languages

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

 http://mentors.debian.net/package/python-bond

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

 dget -x 
http://mentors.debian.net/debian/pool/main/p/python-bond/python-bond_1.4-1.dsc

Changes since the last upload:

 This is my first package and upload to python-modules.

Bug#809657: Recommends non-existing python-gtkspell

[Yuri D'Elia]

Package: virtaal
Version: 0.7.1-1
Severity: normal

python-gtkspell has been removed from the archive.
virtuaal should probably switch to python-gtkspellcheck.

Bug#809520: RFS: trend/1.2-2

[Yuri D'Elia]

On 02/01/16 01:34, Mattia Rizzolo wrote:
> On Fri, Jan 01, 2016 at 06:20:19PM +0100, Yuri D'Elia wrote:
>> On 01/01/16 18:07, Mattia Rizzolo wrote:
>> I remember this, but is a NEWS file still qualified as the classic
>> changelog?
> 
> imho, yes.

I almost expect dh_installchangelogs to look for NEWS in this case
though (I would even argue that it should be looked into first).

Is there a better way to customize the location of the upstream
changelog that I'm missing?

>>>> Updated the source, deleted the old tag (for now), and uploaded again on
>>>> mentors.
> 
> please tag now ;)

Done.
Thanks!

Bug#809520: RFS: trend/1.2-2

[Yuri D'Elia]

On 01/01/16 01:32, Mattia Rizzolo wrote:
> I'd rather look up where you got the .orig.tar.gz file, gbp doesn't
> really deal with it here.

Even when pristine-tar is enabled?
pristine-tar isn't [yet] in this case, as I used import-dscs.

> I mean, of course I'm just going to use the one already in the archive
> for this, and you don't need to use -sa in this case (given that this is
> -2 and the file is already in the archive, everything is going to just
> use that), but I find worrying/weird that you have a different file.

mentors doesn't accept an upload without source (I was refused while
doing so), so I'm forced to do this here.

>>>   + why did you add -Dsrc to the dh command?
>>
>> The main Makefile is inside src/, and I'd avoid to use override_ for
>> most targets. Do you have a better suggestion?

By the way, the current dh manpage uses --sourcedirectory (I cannot find
-D anymore), so I'm using that now.

I'm also a bit thorn about the dh_installchangelogs override.
I now install NEWS with the regular debian/docs.

>>> and btw, before me becoming DD I learned to push the debian/ tags to git
>>> only once the package is uploaded (otherwise now you'll need to
>>> overwrite it...)
>>
>> I didn't realize this was a possibility.
>> It's my first time using both collab-maint and gbp.
> 
> don't worry :)

So what's the policy about fixing this (and the above) in the for the
future repository? I mean, should I squash useless history?

>> I'll have a go at the rest and ping you when it's ready.
> 
> take you time, and thanks for doing it!

Updated the source, deleted the old tag (for now), and uploaded again on
mentors.

Bug#809520: RFS: trend/1.2-2

[Yuri D'Elia]

On 01/01/16 18:07, Mattia Rizzolo wrote:
> See policy 12.7:
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs

I remember this, but is a NEWS file still qualified as the classic
changelog?

As an author, I no longer distribute classical changelogs (fetch it from
the VCS if you need). I only write release summaries.

> "If an upstream changelog is available, it should be accessible as
> /usr/share/doc/package/changelog.gz in plain text."
> 
> So, please revert this.

Done anyway.

>> Updated the source, deleted the old tag (for now), and uploaded again on
>> mentors.
> 
> I also think you errounsly uploaded to ftp-master, didn't you? :)

Yeah, dput's default (now changed in my rc).
Forgot to specify the host.

Re-uploaded.

Bug#809520: RFS: trend/1.2-2

[Yuri D'Elia]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: trend
  Version : 1.2-2
  Upstream Author : Yuri D'Elia <wav...@thregr.org>
* URL : http://www.thregr.org/~wavexx/software/trend
* License : LGPL-2.1
  Section : utils

It builds those binary packages:

  trend - general-purpose, efficient trend graph

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

http://mentors.debian.net/package/trend

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

  dget -x http://mentors.debian.net/debian/pool/main/t/trend/trend_1.2-2.dsc

Changes since the last upload:

This is a packaging refresh, using the latest dh/standars-versions.
I also moved the packaging source to collab-maint and intend to
collaborate with Otto Kekäläinen for further maintenance.

trend (1.2-2) unstable; urgency=low

  * Switch to debhelper 9/quilt.
  * Switch to machine-readable copyright file.
  * Standards-Version 3.9.6 (no changes needed).
  * Move package maintenance to collab-maint.
  * Add Otto Kekäläinen to uploaders.

Regards,
 Yuri D'Elia

Bug#809542: ITP: python-bond -- transparent remote/recursive evaluation between Python and other languages

[Yuri D'Elia]

Package: wnpp
Severity: wishlist
Owner: "Yuri D'Elia" <wav...@thregr.org>

* Package name: python-bond
  Version : 1.4
  Upstream Author : Yuri D'Elia <wav...@thregr.org>
* URL : http://www.thregr.org/~wavexx/software/python-bond/
* License : GPL-2+
  Programming Lang: Python
  Description : transparent remote/recursive evaluation between Python and 
other languages

The Python module ``bond`` supports transparent remote/recursive evaluation
between Python and another interpreter through automatic call serialization.

In poorer words, a ``bond`` lets you call functions in other languages as they
were normal Python functions. It *also* allows other languages to *call Python
functions* as if they were native.

Remote output is also transparently redirected locally, and since the
evaluation is performed through a persistent co-process, you can actually spawn
interpreters on different hosts through "ssh" efficiently.

--

I'm the author. 'bond' has been available on pypi since 2014 and 1.4 is the
latest stable release, which is used heavily and deployed on debian systems in
my current workplace. I'm trying to increase availability through an official
debian package.

Bug#809520: RFS: trend/1.2-2

[Yuri D'Elia]

On 01/01/16 01:12, Mattia Rizzolo wrote:
> though, I'm not satisfied yet:
> * the orig.tar.gz you used to build this release is different than the
>   one in the archive.  it's bigger.  I haven't checked why, but I just
>   can't upload it.

I suspect because my connection is flaky, and had to dput twice
(probably between an incoming scan). I'll have a check. I'm using gbp
buildpackage -sa, so I do not expect issues.

> * in Vcs-Browser please use https and point to the cgit web frontend
> * the changelog is really terse.  please add something about the
>   following changes:
>   + use source format 3.0 (quilt) (I guess that's under the "switch to
> quilt", but it's not clear enough for me.  Also the, "switch to
> debhelper 9" should be something like "bump debhelper compat version
> to 9", after all, debhelper version 9 was here even before the
> compat bump...)
>   + enable hardening
>   + why did you add -Dsrc to the dh command?

The main Makefile is inside src/, and I'd avoid to use override_ for
most targets. Do you have a better suggestion?

> and btw, before me becoming DD I learned to push the debian/ tags to git
> only once the package is uploaded (otherwise now you'll need to
> overwrite it...)

I didn't realize this was a possibility.
It's my first time using both collab-maint and gbp.

I'll have a go at the rest and ping you when it's ready.

Bug#809540: Recommend python3-all as well

[Yuri D'Elia]

Package: python-stdeb
Version: 0.8.5-1
Severity: wishlist

With the general push for python3, I'd advocate for recommending python3-all
and suggesting python3-all-dev in addition to the current dependencies.

Bug#809321: systemd-rfkill state save/restore issues

[Yuri D'Elia]

Package: systemd
Version: 228-2+b1
Severity: normal

[... after a few months wondering why wifi/rfkill doesn't work anymore as it
should, I bump into a newfound systemd-rfkill.service/socket]

I'd like my system to start soft-killed by default. I can do that with
laptop-mode-tools or tlp, but now both conflict in behavior with this service.

Fine for me, but apparently there's no way to make systemd-rfkill do what I
want.

My first question would be, why exactly do I need a *kernel* parameter
(systemd.restore_state) to change the restore behavior?

Looks like we require the state directory to be mounted, so there's no reason
this cannot be specified there. I get this might be useful for boot issues, but
only in *addition* to a configuration file.

Second, restore_state=0 doesn't prevent (as stated) to save at shutdown. If I
could prevent state changes to be saved, I would be fine to restore from my
(manually set) state.

Bug#809323: systemd-rfkill.socket doesn't load at startup

[Yuri D'Elia]

Package: systemd
Version: 228-2+b1
Severity: normal

Occasionally I have trouble with rfkill. Digging in the logs shows that
systemd-rfkill.socket might start too early during boot:

Dec 03 00:25:48 eab14156nb systemd[1]: systemd-rfkill.socket: Socket service 
systemd-rfkill.service not loaded, refusing.
Dec 03 00:25:48 eab14156nb systemd[1]: Failed to listen on Load/Save RF Kill 
Switch Status /dev/rfkill Watch.

Shouldn't it Depend/After explictly systemd-rfkill.service?

Bug#809035: ssh.service notification warning in syslog

[Yuri D'Elia]

On 26/12/15 17:27, Colin Watson wrote:
> Yuri, please could you post the output of "systemctl status -l
> ssh.service"?

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Wed 2015-12-23 11:04:21 CET; 3 days ago
 Main PID: 2576 (sshd)
   CGroup: /system.slice/ssh.service
   └─2576 /usr/sbin/sshd -D

Dec 26 19:51:22 e.thregr.org systemd[1]: ssh.service: Got notification message 
from PID 17587, but reception only permitted for main PID 2576
Dec 26 19:51:22 e.thregr.org sshd[17587]: Accepted publickey for root from ..
Dec 26 19:51:22 e.thregr.org sshd[17587]: pam_unix(sshd:session): session 
opened for user root by (uid=0)

In addition:

# ps -f 17587
UIDPID  PPID  C STIME TTY  STAT   TIME CMD
root 17587  2576  0 19:51 ?Ss 0:00 sshd: root@pts/0

Bug#809035: ssh.service notification warning in syslog

[Yuri D'Elia]

Package: openssh-server
Version: 1:7.1p1-5
Severity: minor

I started to see the following messages in syslog recently:

Dec 22 18:12:36 e systemd[1]: ssh.service: Got notification message from PID 
6719, but reception only permitted for main PID 31374
Dec 22 18:32:55 e systemd[1]: ssh.service: Got notification message from PID 
6783, but reception only permitted for main PID 31374


Is this an useless warning, or a real problem in the ssh service, or ...?