Bug#1019564: (during upgrade) grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..

[Ben Longbons]

Package: grub-pc
Version: 2.06-3~deb11u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: brlongb...@gmail.com

Dear Maintainer,

Today I attempted to upgrade several security and non-security updates
(must have been a point release) as usual. This system is not new, but was
installed in September 2021 (huh, a year ago), and has rebooted fine ...
probably not every week, but every month or so?

This system was installed using mini.iso and telling it to encrypt the
disk. This is all done the traditional way, with an unencrypted separate
/boot partition (which debian-installer stupidly hard-codes to a tiny size
so blocks kernel upgrades occasionally unless you aggressively prune them),
and I've always done this in the past and never had any troubles
before. I also had no problem with grub-pc 2.04-20 which ... hm, looking at
dpkg.log that was the original version I first installed with?

My desktop, which does not use an encrypted disk, accepted the grub-pc
upgrade without error. (for that matter, why is grub getting upgraded at
all on stable? It didn't come through the security ...)

I can't even quit out of aptitude right now? It just keeps prompting in
a loop ...

Based on that prompt I just read from reportbug, it said grub shouldn't
ever be trying to reinstall itself at all??? But it clearly is, and is
failing.

If I manage to hit ^S in the brief moments between fullscreen prompts, the
last messages were:

> Setting up grub-pc (2.06-3~deb11u1) ...
> Installing for i386-pc platform.
> grub-install: warning: Attempting to install GRUB to a disk with multiple 
> partition labels.  This is not supported yet..
> grub-install: warning: Embedding is not possible.  GRUB can only be installed 
> in this setup by using blocklists.  However, blocklists are UNRELIABLE and 
> their use is discouraged..
> grub-install: error: blocklists are invalid.

Then this repeats starting with "Installing for" in an infinite loop if the
default/sane options are chosen in the menus.

The popup screen says:

> Package configuration
> ─┤ Configuring grub-pc ├─
> GRUB failed to install to the following devices:
> /dev/sda1
> Do you want to continue anyway? If you do, your computer may not start
> up properly.
> 
> Writing GRUB to boot device failed - continue?
>  

It sounds like the safe answer is "No" but that's what leads to the
infinite loop. The next screen (with no choice) is:

> Package configuration
> ─┤ Configuring grub-pc ├─
> The grub-pc package is being upgraded. This menu allows you to select
> which devices you'd like grub-install to be automatically run for, if
> any.
> 
> Running grub-install automatically is recommended in most situations, to
> prevent the installed GRUB core image from getting out of sync with GRUB
> modules or grub.cfg.
> 
> If you're unsure which drive is designated as boot drive by your BIOS,
> it is often a good idea to install GRUB to all of them.
> 
> Note: it is possible to install GRUB to partition boot records as well,
> and some appropriate partitions are offered here. However, this forces
> GRUB to use the blocklist mechanism, which makes it less reliable, and
> therefore is not recommended.
> 

And then (clearly /dev/sda is the only possible option here):

> Package configuration
> ─┤ Configuring grub-pc ├─
> GRUB install devices:
> [ ] /dev/dm-0 (999674 MB; sdb5_crypt)
> [*] /dev/sda (1000204 MB; HGST_HTS541010B7E610)
> [ ] - /dev/sda1 (510 MB; /boot)
> [ ] /dev/dm-1 (998647 MB; titan--vg-root)
> 

(not shown: sda2 is the MBR extended partition, and sda5 is the logical
partition just inside it, containing the encrypted LVM container thing. The
installer, as always, is dumb and permanently calls it "sdb5", but this is
just a harmless name. /dev/dm-2 is swap, and is (like dm-1) part of dm-0.
Most of this is in the automatic data dump below, but it seems like
encryption-related setup stuff is not dumped directly)

One oddity I noticed is that if I run `cfdisk /dev/sda` (but not `fdisk` or
`sfdisk`), it gives a strange warning:

> Device already contains a iso9660 signature; it will be removed by a write 
> command.

I have no idea why it thinks my hard drive has an iso9660 signature on it,
but this is the closest thing I can imagine to why GRUB thinks it has
"multiple partition labels".

This hints that the root bug might actually be in some library becoming
overaggressive in its autodetection (isn't ISO9660 is a terribly sloppy
standard like TGA?). But GRUB is the only program I've seen that *exhibits*
the bug.

My *guesses* for how to allow `aptitude` to continue would be either:

* use `cfdisk` and issue a write without changing anything, in hopes that
  whatever it thinks is an ISO9660 label will get wiped out and not lose
  anything important.
* answer "yes" and hope that means my previously-working system gets left
  unchanged.

With this bug, I have officially had more boot problems with Debian stable
than I have on testing/sid machines. (though still nowhere 

Bug#958425: /bin/gzexe: gzexe stub broken (wrong skip=)

[Ben Longbons]

Package: gzip
Version: 1.9-3
Severity: normal
File: /bin/gzexe
Tags: upstream

Dear Maintainer,

skip= is wrong since 5 lines were added (case $TMPDIR ... esac)

Introduced by v1.8-52-g63aa226

Fixed by v1.10-5-g38ae6a4

So both 1.9 (stable) and 1.10 (testing/unstable) are buggy.


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

Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gzip depends on:
ii  dpkg  1.19.7
ii  install-info  6.5.0.dfsg.1-4+b1
ii  libc6 2.28-10

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  487-0.1+b1

-- no debconf information

Bug#930005: regina-rexx: rexxutil error

[Ben Longbons]

Package: libregina3
Version: 3.6-2.1
Followup-For: Bug #930005

Dear Maintainer,

I took a look at this since I thought it would be a simple `-ltinfo`
fix, but it's more complicated than that.

As it is, the package can't possibly run on 64-bit platforms.

There are a *lot* of dangerous warnings; somebody needs to build with
-Werror and fix all of them. This would be a very invasive patch.

If upstream is dead, perhaps the package should simply be removed
from Debian.

-Ben

Bug#929294: xye: Garbage characters are displayed instead of hints

[Ben Longbons]

Package: xye
Version: 0.12.2+dfsg-8
Severity: normal

Dear Maintainer,

In xye.cpp, the following function:

const char* hint::GetActiveText()
{
string res;
if (active==(hint*)(1))
res = globaltext;
else if (active) 
res=active->text;

return res.c_str();
}

returns an invalidated pointer when compiled under the GCC 5 "new ABI".
This was safe on the old ABI, since it used CoW instead of SSO and the
strings the local was copied from are still alive.

Changing the return type to `string` is one fix, or you could
change both branches to `return existing_string.c_str();` directly.

Looking at the rest of the code, there are a lot of cases where a
borrowed pointer from a global or member is returned, both of which are
safe cases.

- Ben


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

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

Versions of packages xye depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libsdl-image1.2  1.2.12-10
ii  libsdl-ttf2.0-0  2.0.11-6
ii  libsdl1.2debian  1.2.15+dfsg2-4
ii  libstdc++6   8.3.0-6
ii  xye-data 0.12.2+dfsg-8

xye recommends no packages.

xye suggests no packages.

-- no debconf information

Bug#820910: apt no longer verifies repositories using sha1 hash

[Ben Longbons]

Package: apt
Version: 1.4.8
Followup-For: Bug #820910

Dear Maintainer,

This also affects pulling old stuff from snapshots.debian.org ... which
is a lot more useful when you can put `[check-valid-until=no]` in
sources.list, which is only in recent apt.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (no /etc/apt/sources.list.d/* present) --


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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2017.5
ii  gpgv2.1.18-8~deb9u1
ii  init-system-helpers 1.48
ii  libapt-pkg5.0   1.4.8
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libstdc++6  6.3.0-18

Versions of packages apt recommends:
ii  gnupg   2.1.18-8~deb9u1
ii  gnupg2  2.1.18-8~deb9u1

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.7-1
ii  dpkg-dev1.18.24
ii  powermgmt-base  1.31+nmu1
pn  python-apt  

-- no debconf information

Bug#881383: systemsettings: Touchpad settings don't actually work

[Ben Longbons]

Package: systemsettings
Version: 4:5.8.4-1
Severity: normal

Dear Maintainer,

In Hardware->Input Devices->Touchpad->Enable/Disable Touchpad:

There is a checkbox "Disable touchpad while typing". However,
even when unchecked (and the system restarted), the touchpad
still disables itself whenever any key is pressed.


Debugging on IRC produced the following observations:

evtest *does* show touchpad events when keys are pressed
but xev does not
and libinput-debug-events does not
(libinput-debug-events --disable-dwt does, however).

libinput-list-devices mentions: Disable-w-typing: enabled

So apparently this is a driver switch or something? Where KDE is only
applying the settings to the driver that isn't actually used anymore.


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

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

Versions of packages systemsettings depends on:
ii  kio   5.28.0-2
ii  libc6 2.24-11+deb9u1
ii  libkf5auth5   5.28.0-2
ii  libkf5completion5 5.28.0-1
ii  libkf5configcore5 5.28.0-2
ii  libkf5configgui5  5.28.0-2
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5dbusaddons5 5.28.0-1
ii  libkf5i18n5   5.28.0-2
ii  libkf5iconthemes5 5.28.0-2
ii  libkf5itemviews5  5.28.0-1
ii  libkf5kcmutils5   5.28.0-2
ii  libkf5khtml5  5.28.0-2
ii  libkf5kiowidgets5 5.28.0-2
ii  libkf5service-bin 5.28.0-1
ii  libkf5service55.28.0-1
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5windowsystem5   5.28.0-2
ii  libkf5xmlgui5 5.28.0-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#879981: gcc-7-plugin-dev: Missing several generated headers

[Ben Longbons]

Package: gcc-7-plugin-dev
Version: 7.2.0-11
Severity: important

Dear Maintainer,

Several of the GCC plugin headers are unusable due to missing files.

I have verified that at least some of this also applies to
gcc-[568]-plugin-dev, but I did my main testing against GCC 7.


The following identifiers are from unknown, missing headers:
MAX_RECOG_OPERANDS
state_t

The following files are missing:
dwarf2.h
gcov-iov.h
gomp-constants.h
insn-opinit.h
insn-target-def.h
partition.h

The following files are unusable/useless generator inputs:
limitx.h
limity.h
params-list.h
params-options.h

The following files conflict with universally-needed headers:
collect-utils.h (bool debug vs function debug - different executable?)
gengtype.h (re-#define'd obstack macros - different executable?)
graphite.h (GCC poisoning affects later ISL system headers)
tsystem.h (useless?)


It is possible that there are more errors in files that also have these
errors, since I stopped looking after the first unrecoverable error in
each file.


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

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

Versions of packages gcc-7-plugin-dev depends on:
ii  gcc-7   7.2.0-11
ii  gcc-7-base  7.2.0-11
ii  libc6   2.24-17
ii  libgmp-dev  2:6.1.2+dfsg-1.1
ii  libmpc-dev  1.0.3-2

gcc-7-plugin-dev recommends no packages.

gcc-7-plugin-dev suggests no packages.

-- no debconf information

Bug#873759: ALc.c:776: LockLists: Assertion `lockret == althrd_success' failed.

[Ben Longbons]

Package: supertuxkart
Version: 0.9.2+dfsg-2
Severity: important

Dear Maintainer,

A reliable one for once!

Whenever the addon level "On the Beach" (not the similarly-named level
"On The Beach" - note the 't'/'T') is chosen, STK aborts while loading
it.

$ coredumpctl gdb supertuxkart
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 31702 (supertuxkart)
   UID: 1000 (ben)
   GID: 1000 (ben)
Signal: 6 (ABRT)
 Timestamp: Wed 2017-08-30 12:30:31 PDT (4min 31s ago)
  Command Line: supertuxkart
Executable: /usr/games/supertuxkart
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (ben)
   Boot ID: b567089063994f90b206df689d65a202
Machine ID: a9f5005691f11289cd92098b52b4f3f9
  Hostname: joyplim
   Storage: 
/var/lib/systemd/coredump/core.supertuxkart.1000.b567089063994f90b206df689d65a202.31702.150412143100.lz4
   Message: Process 31702 (supertuxkart) of user 1000 dumped core.

Stack trace of thread 31721:
#0  0x7f8e4e6fdfff __GI_raise (libc.so.6)
#1  0x7f8e4e6ff42a __GI_abort (libc.so.6)
#2  0x7f8e4e6f6e67 __assert_fail_base (libc.so.6)
#3  0x7f8e4e6f6f12 __GI___assert_fail (libc.so.6)
#4  0x7f8e50ef5ed3 n/a (libopenal.so.1)
#5  0x7f8e50f1227d n/a (libopenal.so.1)
#6  0x7f8e50efea98 alGetSourcei (libopenal.so.1)
#7  0x55fe5da0d0f3 _ZN14MusicOggStream6updateEv 
(supertuxkart)
#8  0x55fe5da0dce9 
_ZN10SFXManager15reallyUpdateNowEPNS_10SFXCommandE (supertuxkart)
#9  0x55fe5da0ec46 _ZN10SFXManager8mainLoopEPv 
(supertuxkart)
#10 0x7f8e51c72494 start_thread (libpthread.so.0)
#11 0x7f8e4e7b3abf __clone (libc.so.6)

Stack trace of thread 31707:
#0  0x7f8e4ec9be4e n/a (libgomp.so.1)
#1  0x7f8e4ec99898 n/a (libgomp.so.1)
#2  0x7f8e51c72494 start_thread (libpthread.so.0)
#3  0x7f8e4e7b3abf __clone (libc.so.6)

Stack trace of thread 31708:
#0  0x7f8e4ec9be4e n/a (libgomp.so.1)
#1  0x7f8e4ec99898 n/a (libgomp.so.1)
#2  0x7f8e51c72494 start_thread (libpthread.so.0)
#3  0x7f8e4e7b3abf __clone (libc.so.6)

Stack trace of thread 31709:
#0  0x7f8e4ec9be4e n/a (libgomp.so.1)
#1  0x7f8e4ec99898 n/a (libgomp.so.1)
#2  0x7f8e51c72494 start_thread (libpthread.so.0)
#3  0x7f8e4e7b3abf __clone (libc.so.6)

Stack trace of thread 31710:
#0  0x7f8e51c7815f pthread_cond_wait@@GLIBC_2.3.2 
(libpthread.so.0)
#1  0x55fe5dc5db2b _ZN6Online14RequestManager8mainLoopEPv 
(supertuxkart)
#2  0x7f8e51c72494 start_thread (libpthread.so.0)
#3  0x7f8e4e7b3abf __clone (libc.so.6)

Stack trace of thread 31702:
#0  0x7f8e4656d77c n/a (libelf.so.1)

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/games/supertuxkart...(no debugging symbols 
found)...done.
[New LWP 31721]
[New LWP 31707]
[New LWP 31708]
[New LWP 31709]
[New LWP 31710]
[New LWP 31702]
[New LWP 31715]
[New LWP 31716]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: Could not find DWO CU 
gallivm/.libs/lp_bld_debug.dwo(0x705e1d0e169ca1fe) referenced by CU at offset 
0x14078a9 [in module 
/usr/lib/debug/.build-id/62/a543423306e4787e29a78fbd94c9a2cdf8ff3d.debug]

warning: Could not find DWO CU 
gallivm/.libs/lp_bld_misc.dwo(0x3f68ad1a054cd591) referenced by CU at offset 
0x1422424 [in module 
/usr/lib/debug/.build-id/62/a543423306e4787e29a78fbd94c9a2cdf8ff3d.debug]
Core was generated by `supertuxkart'.
Program terminated with signal 

Bug#873670: supertuxkart: Segmentation Fault in MusicInformation::isPlaying

[Ben Longbons]

Package: supertuxkart
Version: 0.9.2+dfsg-2
Severity: important

Dear Maintainer,

For me, this occurred during extended play, in story mode, during the
3rd grand prix "to the moon and back", at the very start of the last
race (huh ...  STK keeps grand prix progress on crash), but it is
(naturally) not reproducible.

Unlike most SEGVs, this is a call through a NULL function pointer.

$ coredumpctl gdb supertuxkart
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 27135 (supertuxkart)
   UID: 1000 (ben)
   GID: 1000 (ben)
Signal: 11 (SEGV)
 Timestamp: Tue 2017-08-29 15:43:51 PDT (9min ago)
  Command Line: /usr/games/supertuxkart
Executable: /usr/games/supertuxkart
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (ben)
   Boot ID: b567089063994f90b206df689d65a202
Machine ID: a9f5005691f11289cd92098b52b4f3f9
  Hostname: joyplim
   Storage: 
/var/lib/systemd/coredump/core.supertuxkart.1000.b567089063994f90b206df689d65a202.27135.150404663100.lz4
   Message: Process 27135 (supertuxkart) of user 1000 dumped core.

Stack trace of thread 27135:
#0  0x n/a (n/a)

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/games/supertuxkart...(no debugging symbols 
found)...done.
[New LWP 27135]
[New LWP 27163]
[New LWP 27149]
[New LWP 27147]
[New LWP 27148]
[New LWP 27153]
[New LWP 27159]
[New LWP 27146]
[New LWP 27158]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: Could not find DWO CU 
gallivm/.libs/lp_bld_debug.dwo(0x705e1d0e169ca1fe) referenced by CU at offset 
0x14078a9 [in module 
/usr/lib/debug/.build-id/62/a543423306e4787e29a78fbd94c9a2cdf8ff3d.debug]

warning: Could not find DWO CU 
gallivm/.libs/lp_bld_misc.dwo(0x3f68ad1a054cd591) referenced by CU at offset 
0x1422424 [in module 
/usr/lib/debug/.build-id/62/a543423306e4787e29a78fbd94c9a2cdf8ff3d.debug]
Core was generated by `/usr/games/supertuxkart'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0x7f44fc0ea800 (LWP 27135))]
(gdb) bt
#0  0x in ?? ()
#1  0x55f45bc06cc6 in MusicInformation::isPlaying() const ()
#2  0x55f45be1f811 in WorldStatus::update(float) ()
#3  0x55f45be1a9aa in World::update(float) ()
#4  0x55f45be0d7ec in LinearWorld::update(float) ()
#5  0x55f45be1c31c in World::updateWorld(float) ()
#6  0x55f45be06e90 in MainLoop::run() ()
#7  0x55f45bbc3f96 in main ()
(gdb) up
#1  0x55f45bc06cc6 in MusicInformation::isPlaying() const ()
(gdb) disassemble
Dump of assembler code for function _ZNK16MusicInformation9isPlayingEv:
   0x55f45bc06cb0 <+0>: push   rbx
   0x55f45bc06cb1 <+1>: movrbx,rdi
   0x55f45bc06cb4 <+4>: movrdi,QWORD PTR [rdi+0x98]
   0x55f45bc06cbb <+11>:test   rdi,rdi
   0x55f45bc06cbe <+14>:je 0x55f45bc06cca 
<_ZNK16MusicInformation9isPlayingEv+26>
   0x55f45bc06cc0 <+16>:movrax,QWORD PTR [rdi]
   0x55f45bc06cc3 <+19>:call   QWORD PTR [rax+0x40]
=> 0x55f45bc06cc6 <+22>:test   al,al
   0x55f45bc06cc8 <+24>:jne0x55f45bc06ce8 
<_ZNK16MusicInformation9isPlayingEv+56>
   0x55f45bc06cca <+26>:movrdi,QWORD PTR [rbx+0xa0]
   0x55f45bc06cd1 <+33>:xoreax,eax
   0x55f45bc06cd3 <+35>:test   rdi,rdi
   0x55f45bc06cd6 <+38>:je 0x55f45bc06ce8 
<_ZNK16MusicInformation9isPlayingEv+56>
   0x55f45bc06cd8 <+40>:movrax,QWORD PTR [rdi]
   0x55f45bc06cdb <+43>:poprbx
   0x55f45bc06cdc <+44>:movrax,QWORD PTR [rax+0x40]
   0x55f45bc06ce0 <+48>:jmprax
   0x55f45bc06ce2 <+50>:nopWORD PTR [rax+rax*1+0x0]
   0x55f45bc06ce8 <+56>:poprbx
   0x55f45bc06ce9 <+57>:ret
End of assembler dump.

(as usual, RIP is pointing to where it *would* be if the function returned)

-- System Information:
Debian 

Bug#862315: ipython: [regression] IPython 5.x is very slow to start up

[Ben Longbons]

Package: ipython
Version: 5.1.0-3
Severity: important
Tags: upstream

Dear Maintainer,

Stretch is shipping with ipython 5, which has a major performance
regression compared to previous versions. (not yet fixed in ipython 6)

Startup time has increased from about 1 second (already slow, but tolerable)
to at least 2.5 seconds (my own), and possibly 10 seconds (some reports).

As a workaround, users can use:

neverrunpipasroot@host$ python2 -m pip install --user 'IPython==4.*'
neverrunpipasroot@host$ python3 -m pip install --user 'IPython==4.*'


The upstream issue is https://github.com/ipython/ipython/issues/9908

(The actual issue lies somewhere in pygments, which is a new dependency).

-Ben


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

Kernel: Linux 4.9.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 ipython depends on:
ii  python-ipython  5.1.0-3

ipython recommends no packages.

ipython suggests no packages.

-- no debconf information

Bug#860778: okular: Often fails to open via symlinks

[Ben Longbons]

Package: okular
Version: 4:16.08.2-1+b1
Severity: normal

Dear Maintainer,

The following perfectly-legitimate, common, use of symlinks works with
*all* programs that don't go out of their way to *break* it.

Okular manages to do this wrong, presumably by trying to do filesystem
operations without, you know, talking to the filesystem.


#!/bin/sh
set -e
mkdir -p /tmp/okular-bug/
cd /tmp/okular-bug/
mkdir -p bar/baz
echo 'Hello, World!' > bar/hello.txt
ln -sf bar/baz foo
cat bar/hello.txt
okular bar/hello.txt
cat foo/../hello.txt
okular foo/../hello.txt

-Ben


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

Kernel: Linux 4.9.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 okular depends on:
ii  kde-runtime 4:16.08.3-2
ii  libc6   2.24-10
ii  libfreetype62.6.3-3.1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libkdecore5 4:4.14.26-1
ii  libkdeui5   4:4.14.26-1
ii  libkexiv2-114:15.04.3-1
ii  libkio5 4:4.14.26-1
ii  libkparts4  4:4.14.26-1
ii  libkprintutils4 4:4.14.26-1
ii  libkpty44:4.14.26-1
ii  libokularcore7  4:16.08.2-1+b1
ii  libphonon4  4:4.9.0-4
ii  libpoppler-qt4-40.48.0-2
ii  libqca2 2.1.1-4+b2
ii  libqimageblitz4 1:0.0.6-4+b2
ii  libqmobipocket1 4:16.08.0-1
ii  libqt4-dbus 4:4.8.7+dfsg-11
ii  libqt4-declarative  4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libsolid4   4:4.14.26-1
ii  libspectre1 0.2.8-1
ii  libstdc++6  7-20170407-1
ii  phonon  4:4.9.0-4
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages okular recommends:
ii  cups-bsd  2.2.1-8

Versions of packages okular suggests:
ii  ghostscript9.20~dfsg-3
ii  jovie  4:16.08.0-1+b1
ii  okular-extra-backends  4:16.08.2-1+b1
ii  poppler-data   0.4.7-8
ii  texlive-binaries   2016.20160513.41080.dfsg-2
pn  unrar  

-- no debconf information

Bug#858796: starfighter: SEGV at game_doHud:1821 due to NULL gfx_messageBox

[Ben Longbons]

Package: starfighter
Version: 1.6-1+b1
Severity: normal

Dear Maintainer,

Frequently, I get a crash here, because gfx_messageBox is NULL:

// Show the radio message if there is one
if (gfx_textSprites[TS_RADIO].life > 0)
{
screen_blit(gfx_messageBox, (screen->w - gfx_messageBox->w) / 
2, 50);
gfx_textSprites[TS_RADIO].life--;
}

I'm guessing the big-picture bug has something to do with switching
between the various major screens (combat, menu, etc).

-Ben


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

Kernel: Linux 4.9.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 starfighter depends on:
ii  libc62.24-9
ii  libgcc1  1:7-20161201-1
ii  libsdl2-2.0-02.0.5+dfsg1-2
ii  libsdl2-image-2.0-0  2.0.1+dfsg-2+b2
ii  libsdl2-mixer-2.0-0  2.0.1+dfsg1-1
ii  libstdc++6   7-20161201-1
ii  starfighter-data 1.6-1

starfighter recommends no packages.

starfighter suggests no packages.

-- no debconf information

Bug#856968: /usr/bin/whereis: does not find multiarch libraries

[Ben Longbons]

For libc.so, it only returns the location of the manpage, not the
libraries. It should return `/usr/lib/x86_64-linux-gnu/libc.a
/usr/lib/x86_64-linux-gnu/libc.so`

Try e.g. `whereis libxdg-basedir.so` when `libxdg-basedir-dev` is
installed. It returns the location of the libraries. (non-multiarch
libraries are becoming less common, so it's getting harder to find
something that works)

Since multiarch is a Debian-specific change, upstream has nothing to
do with this.


On Mon, Mar 6, 2017 at 10:55 AM, Andreas Henriksson <andr...@fatal.se> wrote:
> Control: tags -1 + unreproducible moreinfo wontfix upstream
>
> Hello Ben Longbons,
>
> On Mon, Mar 06, 2017 at 10:22:06AM -0800, Ben Longbons wrote:
>> Package: util-linux
>> Version: 2.29.1-1
>> Severity: important
>> File: /usr/bin/whereis
>>
>> Dear Maintainer,
>>
>> On other systems, including old releases of Debian, the command
>> `whereis libc.so` will return the paths to libc.so *and* libc.a
>
> Not for me.
>
> $ dpkg -l util-linux
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---=
> ii  util-linux 2.29.1-1 amd64miscellaneous system utilities
> $ whereis libc.so
> libc: /usr/share/man/man7/libc.7.gz
> $
>
>> On Debian, this only works for non-multiarch'ed libraries.
>
> But libc.so is in a multi-arch location
>
> $ dpkg -L libc6-dev | grep libc.so
> /usr/lib/x86_64-linux-gnu/libc.so
>
> ... so you seem to contradict yourself?!
>
>
>>
>> Although the man page only says "binary", it also includes libraries,
>> as shown by `whereis -l`.
>
> Both libc.so and libc.a are binary files, so not sure what your point is.
>
> Either way, if you want to change the behaviour of something that's been
> working in a certain way for decades you'll want to bring your arguments
> to the upstream development discussion area. That's where development of
> the software happens. I'm also pretty sure there's already been
> another bug report opened on this or similar subject. You might want
> to research the archives to learn from past discussions before
> preparing your argumentation on behaviour change.
>
> Regards,
> Andreas Henriksson

Bug#856968: /usr/bin/whereis: does not find multiarch libraries

[Ben Longbons]

Package: util-linux
Version: 2.29.1-1
Severity: important
File: /usr/bin/whereis

Dear Maintainer,

On other systems, including old releases of Debian, the command
`whereis libc.so` will return the paths to libc.so *and* libc.a
On Debian, this only works for non-multiarch'ed libraries.

Although the man page only says "binary", it also includes libraries,
as shown by `whereis -l`.


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

Kernel: Linux 4.9.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 util-linux depends on:
ii  libblkid1  2.29.1-1
ii  libc6  2.24-9
ii  libfdisk1  2.29.1-1
ii  libmount1  2.29.1-1
ii  libncursesw5   6.0+20161126-1
ii  libpam0g   1.1.8-3.5
ii  libselinux12.6-3
ii  libsmartcols1  2.29.1-1
ii  libsystemd0232-19
ii  libtinfo5  6.0+20161126-1
ii  libudev1   232-19
ii  libuuid1   2.29.1-1
ii  zlib1g 1:1.2.8.dfsg-5

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-1
ii  kbd 2.0.3-2+b1
ii  util-linux-locales  2.29.1-1

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

Bug#854433: firebird3.0-server-core: Please document that this is the package needed to use the embedded mode

[Ben Longbons]

Package: firebird3.0-server-core
Version: 3.0.1.32609.ds4-13
Severity: normal

Dear Maintainer,

For people wanting to use firebird like sqlite3, they need this
"server" package, not just whatever client package. This should be
indicated in the various package descriptions.

Additionally, since most people will not be using *remote* servers, each
client package should have "Recommends: firebird3.0-server-core" and
"Suggests: firebird3.0-server". Note that not all clients necessarily
go through libfbclient2, but I don't know if any of those are in Debian,
or whether they support Embedded mode.

This is particularly important since all the documentation on the
internet only applies to firebird 2.5 and references a nonexistent
'libfbembed.so' (the equivalent is now 'libEngine12.so'), so
`apt-file search` isn't particularly helpful. Also, the error messages
if this package is missing are *very* unhelpful.

-Ben


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32, arm64

Kernel: Linux 4.8.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 firebird3.0-server-core depends on:
ii  firebird3.0-common  3.0.1.32609.ds4-13
ii  firebird3.0-common-doc  3.0.1.32609.ds4-13
ii  libc6   2.24-9
ii  libfbclient23.0.1.32609.ds4-13
ii  libgcc1 1:7-20161201-1
ii  libib-util  3.0.1.32609.ds4-13
ii  libncurses5 6.0+20161126-1
ii  libstdc++6  7-20161201-1
ii  libtinfo5   6.0+20161126-1
ii  libtommath1 1.0-4

firebird3.0-server-core recommends no packages.

Versions of packages firebird3.0-server-core suggests:
pn  firebird3.0-server  

-- no debconf information

Bug#854101: lrzip: Fails to extract its own output when used as a pipe

[Ben Longbons]

Package: lrzip
Version: 0.631-1
Severity: normal

Dear Maintainer,

Sometimes, lrzip can't decode its own output. Oddly, this *only* happens
when the compressor stage is run as a pipe.

I've minimized this testcase from a larger one, in which I used the
entire script I was using to test various compressors as the input.

$ printf 'zp c1 output.1.zpaq input\nzp c2 output.2.zpaq input\nzp c3 
output.3.zpaq input\n' | lrzip | lrunzip | cat
Decompressing...
Compression Ratio: 0.023. Average Compression Speed:  0.000MB/s.
Total time: 00:00:00.06
Failed to decompress buffer - lzmaerr=1
Failed to decompress buffer - lzmaerr=1
Failed to decompress in ucompthread
Fatal error - exiting


Comparing the hexdumps, there are 2 bytes different:

--- bad.lrz.xxd 2017-02-03 21:07:23.196603674 -0800
+++ good.lrz.xxd2017-02-03 21:07:04.824412741 -0800
@@ -1,7 +1,7 @@
 : 4c52 5a49 0006 4e00      LRZI..N.
-0010:   0001  0101 0003  0803  
+0010: 5d00  0101  0101 0003  0803  ]...
 0020:  1603 0a0a  4e00  002a 56c5  N*V.
 0030: 1506 294e  3d1c 0005 3021 cb5e 79bf  ..)N..=...0!.^y.
 0040: 767e cdc4 655e b22c e460 60c9 4d1b c8e2  v~..e^.,.``.M...
 0050: 94e1 5b53 1432 49fd b1b9 e303 7700 180f  ..[S.2I.w...
 0060: 4f46 63ef ea1e 5323 cba3 b743 1d60   OFc...S#...C.`

Thanks,
-Ben


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32, arm64

Kernel: Linux 4.8.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 lrzip depends on:
ii  bash4.4-4
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-9
ii  libgcc1 1:7-20161201-1
ii  liblzo2-2   2.08-1.2
ii  libstdc++6  7-20161201-1
ii  zlib1g  1:1.2.8.dfsg-5

lrzip recommends no packages.

lrzip suggests no packages.

-- no debconf information

Bug#851632: cpio: Crashes when extracting tar file

[Ben Longbons]

Package: cpio
Version: 2.12+dfsg-2
Followup-For: Bug #851632

Dear Maintainer,

I'm just confirming that this still occurs with the version in
experimental. Also, it appears to be completely unrelated to whether
the tarball contains "." - I've tested several variations.

Also, here's a minimal reproducer that proves that cpio can't even
handle its own output:

$ touch empty-file; echo empty-file | cpio --format=tar --create | cpio 
--format=tar --list; rm empty-file
3 blocks
*** Error in `cpio': realloc(): invalid pointer: 0x557b4ec97440 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fc3fc793bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7fc3fc799f96]
/lib/x86_64-linux-gnu/libc.so.6(realloc+0x219)[0x7fc3fc79e5f9]
cpio(+0x19236)[0x557b4ea8c236]
cpio(process_copy_in+0x4bd)[0x557b4ea789dd]
cpio(+0x3e3d)[0x557b4ea76e3d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc3fc7432b1]
cpio(+0x3eda)[0x557b4ea76eda]
=== Memory map: 
557b4ea73000-557b4ea96000 r-xp  fd:01 36223789   
/bin/cpio
557b4ec95000-557b4ec96000 r--p 00022000 fd:01 36223789   
/bin/cpio
557b4ec96000-557b4ec98000 rw-p 00023000 fd:01 36223789   
/bin/cpio
557b501d8000-557b501f9000 rw-p  00:00 0  [heap]
7fc3f800-7fc3f8021000 rw-p  00:00 0 
7fc3f8021000-7fc3fc00 ---p  00:00 0 
7fc3fc463000-7fc3fc479000 r-xp  fd:01 14942495   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3fc479000-7fc3fc678000 ---p 00016000 fd:01 14942495   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3fc678000-7fc3fc679000 r--p 00015000 fd:01 14942495   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3fc679000-7fc3fc67a000 rw-p 00016000 fd:01 14942495   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3fc6cb000-7fc3fc71c000 r--p  fd:01 38939709   
/usr/lib/locale/aa_DJ.utf8/LC_CTYPE
7fc3fc723000-7fc3fc8b8000 r-xp  fd:01 14960680   
/lib/x86_64-linux-gnu/libc-2.24.so
7fc3fc8b8000-7fc3fcab7000 ---p 00195000 fd:01 14960680   
/lib/x86_64-linux-gnu/libc-2.24.so
7fc3fcab7000-7fc3fcabb000 r--p 00194000 fd:01 14960680   
/lib/x86_64-linux-gnu/libc-2.24.so
7fc3fcabb000-7fc3fcabd000 rw-p 00198000 fd:01 14960680   
/lib/x86_64-linux-gnu/libc-2.24.so
7fc3fcabd000-7fc3fcac1000 rw-p  00:00 0 
7fc3fcac3000-7fc3fcae6000 r-xp  fd:01 14942230   
/lib/x86_64-linux-gnu/ld-2.24.so
7fc3fcb13000-7fc3fcb14000 r--p  fd:01 38971026   
/usr/lib/locale/aa_ET/LC_NUMERIC
7fc3fcb1b000-7fc3fcb1c000 r--p  fd:01 38990878   
/usr/lib/locale/en_US.utf8/LC_TIME
7fc3fcb23000-7fc3fcc96000 r--p  fd:01 38861996   
/usr/lib/locale/C.UTF-8/LC_COLLATE
7fc3fcc9b000-7fc3fcc9c000 r--p  fd:01 38987338   
/usr/lib/locale/chr_US/LC_MONETARY
7fc3fcca3000-7fc3fcca4000 r--p  fd:01 38990719   
/usr/lib/locale/en_AG/LC_MESSAGES/SYS_LC_MESSAGES
7fc3fccab000-7fc3fccac000 r--p  fd:01 38987340   
/usr/lib/locale/chr_US/LC_PAPER
7fc3fccb3000-7fc3fccb4000 r--p  fd:01 38987339   
/usr/lib/locale/chr_US/LC_NAME
7fc3fccbb000-7fc3fccbc000 r--p  fd:01 38990876   
/usr/lib/locale/en_US.utf8/LC_ADDRESS
7fc3fccc3000-7fc3fccc4000 r--p  fd:01 38987341   
/usr/lib/locale/chr_US/LC_TELEPHONE
7fc3fcccb000-7fc3f000 r--p  fd:01 38987336   
/usr/lib/locale/chr_US/LC_MEASUREMENT
7fc3fccd3000-7fc3fccda000 r--s  fd:01 38878119   
/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7fc3fccdb000-7fc3fccdc000 r--p  fd:01 38990877   
/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
7fc3fcce-7fc3fcce6000 rw-p  00:00 0 
7fc3fcce6000-7fc3fcce7000 r--p 00023000 fd:01 14942230   
/lib/x86_64-linux-gnu/ld-2.24.so
7fc3fcce7000-7fc3fcce8000 rw-p 00024000 fd:01 14942230   
/lib/x86_64-linux-gnu/ld-2.24.so
7fc3fcce8000-7fc3fcce9000 rw-p  00:00 0 
7ffc0414d000-7ffc0416e000 rw-p  00:00 0  [stack]
7ffc041f3000-7ffc041f5000 r--p  00:00 0  [vvar]
7ffc041f5000-7ffc041f7000 r-xp  00:00 0  [vdso]
[1]3725 done echo empty-file | 
   3726 done cpio --format=tar --create | 
   3727 abort (core dumped)  cpio --format=tar --list



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32, arm64

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#854089: zpaq: missing external preprocessor for min.cfg

[Ben Longbons]

Package: zpaq
Version: 1.10-3
Severity: normal

Dear Maintainer,

The executable `lzppre` is not shipped, so using the included min.cfg
does not work. It is included in the source package, but not built or
installed.

mid.cfg (default) and max.cfg work just fine.

$ zpaq c/usr/share/doc/zpaq/examples/min.cfg output.min.zpaq input
4.264 MB memory required.
lzppre 18 20 127 2 96 input ./output.min.zpaq.zpaq.pre ... sh: 1: lzppre: not 
found
./output.min.zpaq.zpaq.pre: No such file or directory
Archive output.min.zpaq not updated
Process time 0.01 sec. Wall time 0 sec.

-Ben


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32, arm64

Kernel: Linux 4.8.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 zpaq depends on:
ii  libc6   2.24-9
ii  libgcc1 1:7-20161201-1
ii  libstdc++6  7-20161201-1

zpaq recommends no packages.

zpaq suggests no packages.

-- no debconf information

Bug#853915: reportbug: Retrieved base64 messages aren't decoded

[Ben Longbons]

Package: reportbug
Version: 7.1.4
Severity: important

Dear Maintainer,

When running e.g. `reportbug -N 853037`, a bunch of base64 is displayed
instead of the actual content of the messages.

-Ben


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32, arm64

Kernel: Linux 4.8.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 reportbug depends on:
ii  apt1.4~beta4
ii  python3-reportbug  7.1.4
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.89~RC1-1
ii  exim4-daemon-light [mail-transport-agent]  4.89~RC1-1
ii  file   1:5.29-3
ii  gir1.2-gtk-3.0 3.22.7-2
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.18-3
ii  python3-gi 3.22.0-2
ii  python3-gi-cairo   3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.4~beta4
ii  file   1:5.29-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1
pn  python3:any

python3-reportbug suggests no packages.

-- no debconf information

Bug#793106: htop: malfunctions with TERM=linux-16color [was: Some processes running seem to be ‘hidden’ (i.e not showing - except when highlighted)]

[Ben Longbons]

The problem is that TERM=linux-16color is the terminfo entry that is
correct. TERM=linux is the buggy entry, and htop is buggy for using
"bold" when it means "bright".

(I can speak with confidence that I am one of only a few dozen, or
maybe a few hundred, people in the world who understands virtual
terminals at the lowest level. Htop is clearly doing the Wrong Thing™,
using behavior that became obsolete before the Linux kernel even
*existed*. There is absolutely *no* excuse for programs written since
1991 to use it.)

You're doing *something* wrong, since the kernel's terminal emulator
doesn't support underlining. You *must* use ctrl-alt-F1 and reproduce
there.

Also, in order to have the problem in the first place in htop, you
have to have htop's option set, in setup -> display options -> shadow
other user's processes

On Mon, Jan 23, 2017 at 11:30 PM, Daniel Lange  wrote:
> Control: severity -1 minor
> Control: tags -1 moreinfo
>
> TERM=xterm-256color htop # works in xterm from Jessie. No issues.
> TERM=linux-16color htop # works, looks ugly (underlines)
>
> So this all works as intended. Obviously a bad choice of terminal
> emulation will lead to ugly rendering. I *assume* the original reporter
> also had a weird combination of the TERM variable and terminal
> application and that led to only highlighted lines rendering readably.
>
> It is not possible for htop to render correctly in all cases where
> people have broken terminfo, esp. people sshing from Macs etc.
>

Bug#851148: tracker-extract: dumps core repeatedly if seccomp raises SIGSYS

[Ben Longbons]

FYI, your mailer is not using TLS, so it's getting marked a spam.


On Thu, Jan 12, 2017 at 5:07 AM, Simon McVittie  wrote:
>> should log those details
>
> Logging in response to an async signal is problematic: it is not safe
> to use anything much more complicated than a syscall in a signal
> handler (in particular, stdio or GLib logging is a bad idea and
> could deadlock). I think the correct thing here is for tracker-extract
> to just crash, and let system-level diagnostic tools like
> systemd-coredump work out why.

It's quite true that doing anything *complicated* is forbidden. But
there's no need to be complicated.

Just write(2) a newline, a handful of fixed strings, and the hex value
of the syscall and instruction. snprintf(3) isn't safe, but converting
an integer to hex by hand is trivial anyway, compared to using a
seccomp sandbox. Personally, I would've just chrooted (having userns
these days makes sandboxing *so* much easier since you don't need
permissions to become a new "root").

>> During a recent apt run, my system became almost completely
>> unresponsive.
>
> I suspect that the thing stalling your system here is actually
> the repeated core-dump processing, not the repeated
> tracker-extract startup - at least, that has been my experience when
> dealing with repeatedly crashing software. systemd-coredump uses
> relatively expensive compression.

True, but the crashing application is still responsible for the
consequences, especially when it's something that nobody ever asked
for anyway.

Bug#793106: htop: malfunctions with TERM=linux-16color [was: Some processes running seem to be ‘hidden’ (i.e not showing - except when highlighted)]

[Ben Longbons]

FYI, your mailer config is broken, so you're being classified as spam.
Please read https://support.google.com/mail/answer/81126?hl=en#authentication

On Wed, Jan 11, 2017 at 12:57 PM, Daniel Lange  wrote:
> How can I reproduce the issue on Debian Linux?

Pretty much anybody who *ever* edits their ~/.bashrc adds something like:

case $TERM in
xterm) TERM=xterm-256color;;
esac

I just added a second case for linux.

Bug#848523: More info

[Ben Longbons]

Sorry, I've since upgraded my *entire* system from testing to
unstable, and the problem went away at some point.

If it wasn't a bug in some dependency, my guess is that something had
migrated to testing without all of its true dependencies having
migrated. There are a lot of ways that that can happen - plugins,
changes in the *use* of some already-existing library call (e.g.
accepting new enum values).

You can debootstrap from
http://snapshot.debian.org/archive/debian/20161219T152404Z/ to
investigate the underlying cause, since if it's a missing dependency
problem, it *will* cause problems again sooner or later.

But here's the information you requested, for what it's worth:

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Richland [Radeon HD 8610G] [1002:990f] (prog-if 00 [VGA
controller])
Subsystem: Hewlett-Packard Company Richland [Radeon HD 8610G]
[103c:216b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: radeon
Kernel modules: radeon

Bug#848097: terminal.app: Provides x-terminal-emulator, but doesn't implement the requirements

[Ben Longbons]

It's a violation of Policy, so the severity is mandated.

On Sat, Jan 14, 2017 at 9:42 AM, John Paul Adrian Glaubitz
 wrote:
> Control: severity -1 important
>
> Hi Ben!
>
>> Until (or unless) this is implemented, the `Provides:` header and the
>> update-alternatives logic must be removed.
>
> Do you really think that this justifies the severity 'serious' for this bug
> report? With this severity, the package will be removed from testing and
> therefore not be shipping with Debian Stretch.
>
> I don't think this issue justifies such a radical measure, I'll therefore
> downgrade this bug report to 'important'.
>
> Thanks,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#793106: htop: malfunctions with TERM=linux-16color [was: Some processes running seem to be ‘hidden’ (i.e not showing - except when highlighted)]

[Ben Longbons]

Package: htop
Version: 2.0.2-1
Followup-For: Bug #793106

Dear Maintainer,

I just hit this myself, and narrowed down the cause to running with
TERM=linux-16color.

$ infocmp linux linux-16color

comparing linux to linux-16color.
comparing booleans.
comparing numbers.
colors: 8, 16.
ncv: 18, 42.
pairs: 64, 256.
comparing strings.
setab: '\E[4%p1%dm', '\E[4%p1%{8}%m%d%?%p1%{7}%>%t;5%e;25%;m'.
setaf: '\E[3%p1%dm', '\E[3%p1%{8}%m%d%?%p1%{7}%>%t;1%e;21%;m'.

In particular, `ncv` for linux-16color includes `A_BOLD` and `A_BLINK`.
(It is, buggily, missing `A_DIM` since the termianal includes the `dim`
capability, but it correctly lacks `A_ITALIC` since it doesn't have `stitm`).

From terminfo(5):

   On some color terminals, colors collide with highlights.  You can  reg‐
   ister  these collisions with the ncv capability.  This is a bit-mask of
   attributes not to be used when colors are enabled.  The  correspondence
   with the attributes understood by curses is as follows:

Attribute  Bit   Decimal  Set by
A_STANDOUT 0 1sgr
A_UNDERLINE1 2sgr
A_REVERSE  2 4sgr
A_BLINK3 8sgr
A_DIM  4 16   sgr
A_BOLD 5 32   sgr
A_INVIS6 64   sgr
A_PROTECT  7 128  sgr
A_ALTCHARSET   8 256  sgr
A_HORIZONTAL   9 512  sgr1
A_LEFT 101024 sgr1
A_LOW  112048 sgr1
A_RIGHT124096 sgr1
A_TOP  138192 sgr1
A_VERTICAL 1416384sgr1
A_ITALIC   1532768sitm

   For  example, on many IBM PC consoles, the underline attribute collides
   with the foreground color blue and is  not  available  in  color  mode.
   These should have an ncv capability of 2.

   SVr4  curses does nothing with ncv, ncurses recognizes it and optimizes
   the output in favor of colors.

When TERM=linux, htop is *manually* assuming it can get 16 colors on an
8-color terminal using bold/blink (which happens to work on some terminals,
but is generally *not* reliable).

The correct thing to do is to use native support for 16 colors when
available, and fall back to 8 colors *without* bold/blink otherwise
(making sure to adjust the foreground if it matches the background -
dark blue is a common choice for black-on-black).

If you want to assume that everybody claiming they're TERM=linux really
supports 16 colors (remember that lots of terminal emulators lie! But -C
mode should suffice for liars), you should unconditionally change the
TERM=linux to TERM=linux-16color in the environment at startup.

As a short-term workaround (to avoid fixing all the buggy calls), do the
opposite: change TERM=linux-16color to TERM=linux during startup.

If there are any terminal entries which claim to only support 8 colors
but can actually support 16, they should have a similar terminfo entry
written if one doesn't already exist.

-Ben


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

Kernel: Linux 4.8.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 htop depends on:
ii  libc6 2.24-8
ii  libncursesw5  6.0+20161126-1
ii  libtinfo5 6.0+20161126-1

htop recommends no packages.

Versions of packages htop suggests:
ii  lsof4.89+dfsg-0.1
ii  strace  4.15-2

-- no debconf information

Bug#849297: /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so: broken symbolic link

[Ben Longbons]

Package: libsdl2-dev
Version: 2.0.5+dfsg1-1
Severity: normal
File: /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so

Dear Maintainer,

I'm not sure who (if anyone) wants -lSDL2-2.0 rather than -lSDL2 (which is
what pkg-config and sdl2-config give), but the link is broken for them.

libSDL2-2.0.so -> libSDL2-2.0.so.0.4.0
libSDL2.so -> libSDL2-2.0.so.0.4.1

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

Kernel: Linux 4.8.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 libsdl2-dev depends on:
ii  libasound2-dev 1.1.2-1
ii  libdbus-1-dev  1.10.14-1
ii  libegl1-mesa-dev   13.0.2-3
ii  libgl1-mesa-dev13.0.2-3
ii  libgles2-mesa-dev  13.0.2-3
ii  libglu1-mesa-dev   9.0.0-2.1
ii  libibus-1.0-dev1.5.14-2
ii  libpulse-dev   9.0-5
ii  libsdl2-2.0-0  2.0.5+dfsg1-1
ii  libsndio-dev   1.1.0-3
ii  libudev-dev232-8
ii  libwayland-dev 1.12.0-1
ii  libx11-dev 2:1.6.4-2
ii  libxcursor-dev 1:1.1.14-1+b1
ii  libxext-dev2:1.3.3-1
ii  libxi-dev  2:1.7.8-1
ii  libxinerama-dev2:1.1.3-1+b1
ii  libxkbcommon-dev   0.7.0-1
ii  libxrandr-dev  2:1.5.1-1
ii  libxss-dev 1:1.2.2-1
ii  libxt-dev  1:1.1.5-1
ii  libxv-dev  2:1.0.11-1
ii  libxxf86vm-dev 1:1.1.4-1

libsdl2-dev recommends no packages.

libsdl2-dev suggests no packages.

-- no debconf information

Bug#849113: /lib/lsb/init-functions: When echoing status messages, use \r\n instead of \n in case the terminal is in ~OPOST mode

[Ben Longbons]

Package: lsb-base
Version: 9.20161125
Severity: wishlist
File: /lib/lsb/init-functions

Dear Maintainer,

When a terminal is in raw mode (in particular, when OPOST is not set in
termios.c_oflag, which disables the effect of ONLCR), emitting a \n will
only move the cursor down one line, rather than implicitly adding a \r
to move to the start of the line.

In particular, this often happens when restarting the display manager.

To fix, simply ensure that every \n is preceded by a \r. As long as this
is only done when output is a terminal, it won't mess up any log files.

-Ben


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

Kernel: Linux 4.8.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)

-- no debconf information

Bug#848842: /usr/lib/tracker/tracker-extract: Crashes with SIGSYS, and repeatedly restarts

[Ben Longbons]

Package: tracker-extract
Version: 1.10.3-1
Followup-For: Bug #848842

Dear Maintainer,

> severity 848842 important

If this isn't 'critical', I have no idea what is. Should I have waited
until the rest of the OS was swapped out so that I *couldn't* kill it?

Just because it's `Priority: optional` doesn't mean it's not an RC bug
within that package.


Anyway, I got the debug symbols, but it looks like I just need the
syscall numbers ($orig_rax in all threads):

/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_poll 7
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_mlock 149
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_futex 202
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_ppoll 271

Remember, SIGSYS is catchable, and the siginfo_t contains details. If a
program is going to use `seccomp`, it should log those details, before
exiting with a value that tells systemd not to restart it.

-Ben


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

Kernel: Linux 4.8.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 tracker-extract depends on:
ii  libc6   2.24-8
ii  libcue1 1.4.0-1
ii  libflac81.3.1-4
ii  libgif7 5.1.4-0.4
ii  libglib2.0-02.50.2-2
ii  libgsf-1-1141.14.41-1
ii  libgstreamer-plugins-base1.0-0  1.10.2-1
ii  libgstreamer1.0-0   1.10.2-1
ii  libgxps20.2.4-1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libmediaart-2.0-0   1.9.0-2
ii  libosinfo-1.0-0 1.0.0-2
ii  libpng16-16 1.6.26-6
ii  libpoppler-glib80.48.0-2
ii  libtiff54.0.7-3
ii  libtotem-plparser18 3.10.7-1
ii  libtracker-miner-1.0-0  1.10.3-1
ii  libtracker-sparql-1.0-0 1.10.3-1
ii  libvorbisfile3  1.3.5-3
ii  libxml2 2.9.4+dfsg1-2.1
ii  tracker 1.10.3-1

tracker-extract recommends no packages.

tracker-extract suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/tracker-extract.desktop changed [not included]

-- no debconf information

Bug#848842: /usr/lib/tracker/tracker-extract: Crashes with SIGSYS, and repeatedly restarts

[Ben Longbons]

Package: tracker-extract
Version: 1.10.3-1
Severity: critical
File: /usr/lib/tracker/tracker-extract
Justification: breaks the whole system

Dear Maintainer,

During a recent apt run, my system became almost completely
unresponsive.

Luckily I was able to get to another terminal, find the offender with
`top`, and neutralize it.

/usr/lib/tracker/tracker-extract is dying with SIGSYS, backtrace below.

According to `coredumpctl list`, it restarted approximately 6000 times
before I replaced it with a symlink to /bin/true, which finally allowed
aptitude to finish. That auto-restart behavior, in itself, deserves a grave
bug at least.

I haven't got debug symbols, but I will follow-up after installing them.

# coredumpctl gdb
   PID: 23962 (tracker-extract)
   UID: 1000 (ben)
   GID: 1000 (ben)
Signal: 31 (SYS)
 Timestamp: Mon 2016-12-19 21:16:42 PST (12min ago)
  Command Line: /usr/lib/tracker/tracker-extract
Executable: /usr/lib/tracker/tracker-extract
 Control Group: /
 Slice: -.slice
   Boot ID: db830d9ceb0441bd97c414fa76830061
Machine ID: a9f5005691f11289cd92098b52b4f3f9
  Hostname: joyplim
   Storage: 
/var/lib/systemd/coredump/core.tracker-extract.1000.db830d9ceb0441bd97c414fa76830061.23962.1482211002.lz4
   Message: Process 23962 (tracker-extract) of user 1000 dumped core.

Stack trace of thread 23990:
#0  0x7fe59d43e4d7 mlock (libc.so.6)
#1  0x7fe5766da6f1 fluid_defsfont_load_sampledata 
(libfluidsynth.so.1)
#2  0x7fe5766de78a fluid_defsfont_load (libfluidsynth.so.1)
#3  0x7fe5766de8c1 fluid_defsfloader_load 
(libfluidsynth.so.1)
#4  0x7fe5766ebdc9 fluid_synth_sfload (libfluidsynth.so.1)
#5  0x7fe57698d276 n/a (libgstfluidsynthmidi.so)
#6  0x7fe58647d6de gst_element_change_state 
(libgstreamer-1.0.so.0)
#7  0x7fe58647de4f n/a (libgstreamer-1.0.so.0)
#8  0x7fe584266edd n/a (libgstplayback.so)
#9  0x7fe5842725c4 n/a (libgstplayback.so)
#10 0x7fe584272fe2 n/a (libgstplayback.so)
#11 0x7fe58427322f n/a (libgstplayback.so)
#12 0x7fe59dc41f75 g_closure_invoke (libgobject-2.0.so.0)
#13 0x7fe59dc53f82 signal_emit_unlocked_R 
(libgobject-2.0.so.0)
#14 0x7fe59dc5cbcc g_signal_emit_valist 
(libgobject-2.0.so.0)
#15 0x7fe59dc5cfaf g_signal_emit (libgobject-2.0.so.0)
#16 0x7fe59dc463a4 g_object_dispatch_properties_changed 
(libgobject-2.0.so.0)
#17 0x7fe586451634 n/a (libgstreamer-1.0.so.0)
#18 0x7fe59dc48979 g_object_notify_by_spec_internal 
(libgobject-2.0.so.0)
#19 0x7fe586492434 n/a (libgstreamer-1.0.so.0)
#20 0x7fe58649ded0 gst_pad_push_event 
(libgstreamer-1.0.so.0)
#21 0x7fe577397829 n/a (libgstmidi.so)
#22 0x7fe5864c8a11 n/a (libgstreamer-1.0.so.0)
#23 0x7fe59d98cd3e g_thread_pool_thread_proxy 
(libglib-2.0.so.0)
#24 0x7fe59d98c345 g_thread_proxy (libglib-2.0.so.0)
#25 0x7fe59d701464 start_thread (libpthread.so.0)
#26 0x7fe59d4429df __clone (libc.so.6)

Stack trace of thread 23964:
#0  0x7fe59d43e119 syscall (libc.so.6)
#1  0x7fe59d9aa14f g_cond_wait (libglib-2.0.so.0)
#2  0x7fe59d938ecb g_async_queue_pop_intern_unlocked 
(libglib-2.0.so.0)
#3  0x7fe59d98ce8d g_thread_pool_wait_for_new_task 
(libglib-2.0.so.0)
#4  0x7fe59d98c345 g_thread_proxy (libglib-2.0.so.0)
#5  0x7fe59d701464 start_thread (libpthread.so.0)
#6  0x7fe59d4429df __clone (libc.so.6)

Stack trace of thread 23962:
#0  0x7fe59d43956d poll (libc.so.6)
#1  0x7fe59d9649f6 g_main_context_poll (libglib-2.0.so.0)
#2  0x7fe59d964d82 g_main_loop_run (libglib-2.0.so.0)
#3  0x56523e970d47 n/a (/usr/lib/tracker/tracker-extract)

GNU gdb (Debian 7.12-4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:

Bug#848818: xterm: ctlseqs.txt is not rebuilt from ctlseq.ms

[Ben Longbons]

On Mon, Dec 19, 2016 at 3:48 PM, Thomas Dickey <dic...@his.com> wrote:
> On Mon, Dec 19, 2016 at 02:39:27PM -0800, Ben Longbons wrote:
>> The ctlseqs.txt file is not built from ctlseqs.ms if it is modified
>> (which it should be, since it is wrong in a few places).
>
> I don't recall any bug reports on the topic.

I was working on that when I hit this. Besides the one you mentioned,
the xterm-specific `DECSED 3` is missing, for example. I'm sure there
was something with one of the string controls too ...

> ctlseqs.txt is part of the upstream sources, has been since June 2006.

Source means "preferred format for modification", not "in a tarball
somewhere". By your definititon, all of Windows is open-source.

>> * Remove the -P options to preserve formatting, less can handle it.
>
> The makefile doesn't use -P.

By using environment variables and extra pipe commands. But in any
case, a version *without* stripping all that formatting info, viewable
in the terminal, would be nice.

> no.  It's an ASCII file.  Pretty bullets don't help much, considering that
> less than 1% of the file uses that.  For interesting typography, refer to
> the PDF.

That's a matter of opinion. Using the letter `o` for bullets is
particular ugly to me.

>> * -Thtml
>>
>> The html and pdf formats provide significant features not in the txt
>
> groff's html format isn't useful.  I don't use that anymore:

You mean the format that is identical to the format you produce, other
than the (admittedly better) filenames for the included `.png`s?

-Ben

Bug#848824: trigger-rally: File conflict: /usr/share/man/man6/trigger-rally.6.gz in both packages

[Ben Longbons]

Package: trigger-rally
Version: 0.6.5+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With this version, the man page is now shipped in the -data package as
well as the main package.

You should remove it from the main package, and give appropiate
Breaks/Conflicts/Provides.


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

Kernel: Linux 4.8.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 trigger-rally depends on:
ii  libalut0  1.1.0-5
ii  libc6 2.24-8
ii  libgcc1   1:7-20161201-1
ii  libgl1-mesa-glx [libgl1]  13.0.2-3
ii  libglew2.02.0.0-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libopenal11:1.17.2-4
ii  libphysfs12.0.3-3+b1
ii  libsdl2-2.0-0 2.0.5+dfsg1-1
ii  libsdl2-image-2.0-0   2.0.1+dfsg-2+b2
ii  libstdc++67-20161201-1
ii  libtinyxml2-4 4.0.1-1
ii  trigger-rally-data0.6.4+dfsg-2

trigger-rally recommends no packages.

trigger-rally suggests no packages.

-- no debconf information

Bug#848818: xterm: ctlseqs.txt is not rebuilt from ctlseq.ms

[Ben Longbons]

Package: xterm
Version: 327-2
Severity: serious
Justification: Policy 2.1

Dear Maintainer,

The ctlseqs.txt file is not built from ctlseqs.ms if it is modified
(which it should be, since it is wrong in a few places).

The command to bytewise-reproduce the existing file is:

$ groff -P{-c,-b,-o,-u} -Tascii -t -ms < ctlseqs.ms > ctlseqs.txt

Note: You need to add a build-dep on `groff`, not just `groff-base`,
in order to install the macro packages `-ms`.

But there are some *better* command variants.

* Remove the -P options to preserve formatting, less can handle it.
* -Tutf8 (better quotes/bullets; the VT fonts have everything they need).
* -Tpdf
* -Thtml

The html and pdf formats provide significant features not in the txt
version, though the PDF doesn't have a Table of Contents.

-Ben


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

Kernel: Linux 4.8.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 xterm depends on:
ii  libc6   2.24-8
ii  libfontconfig1  2.11.0-6.7
ii  libice6 2:1.0.9-1+b1
ii  libtinfo5   6.0+20161126-1
ii  libutempter01.1.6-3
ii  libx11-62:1.6.4-2
ii  libxaw7 2:1.0.13-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxmu6 2:1.1.2-2
ii  libxpm4 1:3.5.11-1+b1
ii  libxt6  1:1.1.5-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+3

Versions of packages xterm suggests:
ii  xfonts-cyrillic  1:1.0.4

-- no debconf information

Bug#848655: reportbug crashes with error "TypeError: * wants int"

[Ben Longbons]

Package: reportbug
Version: 7.1.1
Followup-For: Bug #848655

Dear Maintainer,

I suspect the problem is this line:

maxlen_name = min(max(list(map(len, allowed))), columns / 3)

Since in Python3, / returns a float. Use // instead.

-- Package-specific info:
** Environment settings:
PAGER="less"
INTERFACE="text"

** /home/ben/.reportbugrc:
reportbug_version "5.1.1"
mode standard
ui text
email "brlongb...@gmail.com"
smtphost smtp.gmail.com:587
smtpuser "brlongb...@gmail.com"
smtptls

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

Kernel: Linux 4.8.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 reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.1
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88~RC6-1
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-1
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.5-1
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.16-3
ii  python3-gi 3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

-- no debconf information

Bug#848696: valgrind: prerm fails: dpkg-maintscript-helper: error: dpkg: error: version '' has bad syntax: version string is empty

[Ben Longbons]

Package: valgrind
Version: 1:3.12.0~svn20160714-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

It is not possible to upgrade to 1:3.12.0-1 because the prerm fails.

Complete output of an aptitude run:


Performing actions...
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 1108901 files and directories currently installed.)
Preparing to unpack .../0-valgrind_1%3a3.12.0-1_amd64.deb ...
dpkg-maintscript-helper: error: dpkg: error: version '' has bad syntax: version 
string is empty
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg-maintscript-helper: error: dpkg: error: version '' has bad syntax: version 
string is empty
dpkg: error processing archive 
/tmp/apt-dpkg-install-GkHIOX/0-valgrind_1%3a3.12.0-1_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
dpkg-maintscript-helper: error: dpkg: error: version '' has bad syntax: version 
string is empty
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1
Preparing to unpack .../1-dpkg_1.18.17_amd64.deb ...
Unpacking dpkg (1.18.17) over (1.18.16) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-GkHIOX/0-valgrind_1%3a3.12.0-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up dpkg (1.18.17) ...
Processing triggers for man-db (2.7.6.1-2) ...
dpkg: error processing package valgrind (--configure):
 package is in a very bad inconsistent state; you should
 reinstall it before attempting configuration
dpkg: dependency problems prevent configuration of valgrind-dbg:
 valgrind-dbg depends on valgrind (= 1:3.12.0-1); however:
  Version of valgrind on system is 1:3.12.0~svn20160714-1+b1.

dpkg: error processing package valgrind-dbg (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 valgrind
 valgrind-dbg
Press Return to continue, 'q' followed by Return to quit.


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

Kernel: Linux 4.8.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 valgrind depends on:
ii  libc6  2.24-8
ii  libc6-dbg  2.24-8

Versions of packages valgrind recommends:
ii  gdb   7.12-4
iu  valgrind-dbg  1:3.12.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

Bug#848602: Depends: nodejs-legacy

[Ben Longbons]

Package: libkf5purpose-bin
Version: 1.1-3
Severity: serious
Justification: Policy 10.1

Dear Maintainer,

Per CTTE decree, packages may not depend on nodejs-legacy. It exists
solely for compatibility with non-Debian packages that are unaware of
the fact that someone else claimed the name 'node' many years before.

For details, see bug #614907 and
https://lists.debian.org/debian-devel-announce/2012/07/msg2.html

-Ben


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

Kernel: Linux 4.8.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#848524: kwin-wayland: rapid memory leak

[Ben Longbons]

Package: kwin-wayland
Version: 4:5.8.4-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since kwin-x11 was being even crashier than usual, I tried the other
Plasma (wayland) entry for a change.

To my great joy, it worked flawlessly ... for the first several minutes.

After that, however, everything became nonresponsive, and I observed
kwin-wayland using over 2GB each of both RAM and SWAP as I killed it.

I'm not desperate enough to use GNOME, so I'm stuck on the CLI for now.

-Ben


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

Kernel: Linux 4.8.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 kwin-wayland depends on:
ii  kwayland-integration 5.8.4-1
ii  kwin-common  4:5.8.4-1
ii  kwin-wayland-backend-drm [kwin-wayland-backend]  4:5.8.2-1+b1
ii  libc62.24-8
ii  libepoxy01.3.1-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libkf5coreaddons55.27.0-1
ii  libkf5i18n5  5.27.0-2
ii  libkf5idletime5  5.27.0-1
ii  libkf5waylandclient5 4:5.28.0-1
ii  libkf5waylandserver5 4:5.28.0-1
ii  libkf5windowsystem5  5.27.0-1
ii  libkwineffects9  4:5.8.4-1
ii  libqt5core5a [qtbase-abi-5-7-1]  5.7.1~20161021+dfsg-6
ii  libqt5dbus5  5.7.1~20161021+dfsg-6
ii  libqt5gui5   5.7.1~20161021+dfsg-6
ii  libqt5widgets5   5.7.1~20161021+dfsg-6
ii  libstdc++6   7-20161201-1
ii  libwayland-egl1-mesa [libwayland-egl1]   13.0.2-1
ii  libxcb1  1.12-1
ii  qtwayland5   5.7.1~20161021-2
ii  xwayland 2:1.19.0-2

kwin-wayland recommends no packages.

kwin-wayland suggests no packages.

-- no debconf information

Bug#848523: kwin-x11: Fails to start

[Ben Longbons]

Package: kwin-x11
Version: 4:5.8.4-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With some recent upgrade, kwin-x11 fails to start properly. Usually I
track testing, but .

I can see the process *running*, but it doesn't actually decorate any
windows (if I manually e.g. start an xterm), and plasma never even gets
started.

Starting a different window manager *sometimes* allows Plasma to start,
but not reliably - I'm not sure how startkde waits for the WM to
activate.

While kwin *has* been unstable in the past, usually just killing the
drkonqi processes would fix everything.

-Ben


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

Kernel: Linux 4.8.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 kwin-x11 depends on:
ii  kwin-common   4:5.8.4-1
ii  libc6 2.24-8
ii  libepoxy0 1.3.1-1
ii  libgcc1   1:7-20161201-1
ii  libkf5configcore5 5.27.0-1
ii  libkf5coreaddons5 5.27.0-1
ii  libkf5crash5  5.27.0-1
ii  libkf5i18n5   5.27.0-2
ii  libkf5windowsystem5   5.27.0-1
ii  libkwinglutils9   4:5.8.2-1+b1
ii  libkwinxrenderutils9  4:5.8.2-1+b1
ii  libqt5core5a  5.7.1~20161021+dfsg-6
ii  libqt5gui55.7.1~20161021+dfsg-6
ii  libqt5widgets55.7.1~20161021+dfsg-6
ii  libqt5x11extras5  5.7.1~20161021-2
ii  libstdc++67-20161201-1
ii  libx11-6  2:1.6.4-2
ii  libxcb-cursor00.1.1-3
ii  libxcb-randr0 1.12-1
ii  libxcb-xfixes01.12-1
ii  libxcb1   1.12-1
ii  libxi62:1.7.8-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#848162: konsole: Interprets options even after -e

[Ben Longbons]

Package: konsole
Version: 4:16.08.3-1
Severity: serious
Justification: Policy 11.8.3

Dear Maintainer,


Quoting policy:

>To be an x-terminal-emulator, a program must:

> * Support the command-line option -e command, which creates a new terminal 
> window[106] and runs the specified command, interpreting the entirety of the 
> rest of the command line as a command to pass straight to exec, in the manner 
> that xterm does.


While konsole *almost* does this, the following minimal example fails:

$ konsole -e sh -c sh
Unknown option 'c'.

(Incidentally, bug #563352 is totally bogus and can be closed - policy
should be updated to clarify "in the manner that xterm does when argv0
has no space").


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

Kernel: Linux 4.8.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 konsole depends on:
ii  kio   5.27.0-2
ii  konsole-kpart 4:16.08.3-1
ii  libc6 2.24-7
ii  libkf5completion5 5.27.0-1
ii  libkf5configcore5 5.27.0-1
ii  libkf5configgui5  5.27.0-1
ii  libkf5configwidgets5  5.27.0-1
ii  libkf5coreaddons5 5.27.0-1
ii  libkf5crash5  5.27.0-1
ii  libkf5dbusaddons5 5.27.0-1
ii  libkf5i18n5   5.27.0-2
ii  libkf5iconthemes5 5.27.0-1
ii  libkf5kiowidgets5 5.27.0-2
ii  libkf5notifyconfig5   5.27.0-1
ii  libkf5widgetsaddons5  5.27.0-1
ii  libkf5windowsystem5   5.27.0-1
ii  libkf5xmlgui5 5.27.0-1
ii  libqt5core5a  5.7.1~20161021+dfsg-6
ii  libqt5gui55.7.1~20161021+dfsg-6
ii  libqt5widgets55.7.1~20161021+dfsg-6
ii  libstdc++67-20161201-1

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#848097: terminal.app: Provides x-terminal-emulator, but doesn't implement the requirements

[Ben Longbons]

Package: terminal.app
Version: 0.9.8-1+nmu1+b2
Severity: serious
Justification: Policy 11.8.3

Dear Maintainer,

Quoting policy:

>To be an x-terminal-emulator, a program must:

> * Be able to emulate a DEC VT100 terminal, or a compatible terminal.

> * Support the command-line option -e command, which creates a new terminal 
> window[106] and runs the specified command, interpreting the entirety of the 
> rest of the command line as a command to pass straight to exec, in the manner 
> that xterm does.

> * Support the command-line option -T title, which creates a new terminal 
> window with the window title title.

/usr/bin/Terminal appears to not have *any*, options, not even `--help`.

Until (or unless) this is implemented, the `Provides:` header and the
update-alternatives logic must be removed.

-Ben


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

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 terminal.app depends on:
ii  libc62.24-7
ii  libgnustep-base1.24  1.24.9-3
ii  libgnustep-gui0.25   0.25.0-4
ii  libobjc4 6.2.1-5

terminal.app recommends no packages.

terminal.app suggests no packages.

-- no debconf information

Bug#848096: guake: Provides x-terminal-emulator, but doesn't implement the requirements

[Ben Longbons]

Package: guake
Version: 0.8.7-1
Severity: serious
Justification: Policy 11.8.3

Dear Maintainer,

Quoting policy:

>To be an x-terminal-emulator, a program must:

> * Be able to emulate a DEC VT100 terminal, or a compatible terminal.

Guake does this one, at least.

> * Support the command-line option -e command, which creates a new terminal 
> window[106] and runs the specified command, interpreting the entirety of the 
> rest of the command line as a command to pass straight to exec, in the manner 
> that xterm does.

Guake implements this incorrectly - it uses the shell's -c option
rather than consuming the rest of the arguments.

This is the reason for gnome-terminal.wrapper, though the underlying
functionality will need to be implemented at all before a wrapper can be
written.

Also, it does not make the terminal visible, and behaves quite oddly
if run from outside an existing guake.

> * Support the command-line option -T title, which creates a new terminal 
> window with the window title title.

Guake does not implement this at all. The `-r` argument DTWT if already
within a guake terminal, doesn't make the terminal visible, and doesn't
block.


Since guake is a somewhat special-purpose terminal, the simplest solution is
to simply remove the `Provides:` header and the `update-alternatives` logic.
(This doesn't stop *users* from using guake primarily, of course).

If you *do* decide to implement the missing requirements, take care that
the caller blocks for the right duration in all cases: (if starting guake
for the first time; if guake was already running; if run from within guake).

-Ben


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

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 guake depends on:
ii  gconf2  3.2.6-4
ii  libgtk2.0-0 2.24.31-1
ii  notification-daemon 3.20.0-1
ii  plasma-workspace [notification-daemon]  4:5.8.2-1
ii  python  2.7.11-2
ii  python-dbus 1.2.4-1
ii  python-gconf2.28.1+dfsg-1.2
ii  python-glade2   2.24.0-5.1
ii  python-keybinder0.3.1-1
ii  python-notify   0.1.1-4
ii  python-vte  1:0.28.2-5+b1
ii  python-xdg  0.25-4
ii  python2.7   2.7.12-7
pn  python:any  

guake recommends no packages.

guake suggests no packages.

-- no debconf information

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

On Fri, Dec 9, 2016 at 1:46 PM, Paul Gevers  wrote:
> I am trying to understand you shell script

You may find it easier to just run it and inspect the resulting
`.deb`s, then refer to the script only when you want to see where a
specific path/package is handled.

> Just to make sure I am not completely
> misunderstanding, you are trying to use binutils- package
> on the arch of that triplet, right? But e.g. binutils-aarch64-linux-gnu
> doesn't exist on amd64.

Er, yes it does:
https://packages.debian.org/search?keywords=binutils-aarch64-linux-gnu

The *only* packages that are "missing" (actually just outdated and
with wrong headers) are the two x86 arches that are still from
src:cross-binutils rather than src:binutils, for which I filed bug
#846628.

>> Note that the
>> new /etc/fpc/debian.cfg must be installed from the *unversioned*
>> package - which will require a "backwards" dependency
>> (fp-compiler-config-3.0.0 depends on fp-compiler-config-common).
>
> Can you explain where this requirement comes from? If really required,
> then we'll have to figure out an other solution, because circular
> dependencies are a problem.

Background: managing /etc/fpc.cfg via update-alternatives is
fundamentally wrong, because it is the file read by *all* installed
versions of fpc. In order for each FPC to use its *own* fpc.cfg, they
all need to be conditionally included from a *single* fpc.cfg. Since
jessie shipped with packages that manage /etc/fpc.cfg via
update-alternatives, the symlink must still be managed by it for the
stretch upgrade (for the stretch -> buster upgrade this will no longer
be the case).

Fix: Regardless of version, make /etc/fpc.cfg a symlink to
/etc/fpc/debian.cfg file, which then includes the files specific to
the arch and version.

So the hard dependencies will be:

fp-compiler:$a -> fp-compiler-$v:$a
fp-compiler-$v:$a -> fp-compiler-config-$v:all,
fp-compiler-driver-$v(:$a, but Multi-Arch:foreign)
fp-compiler-config-$v:all -> fp-compiler-config-common:all

(Additionally, fp-compiler-driver-$v should have a backwards
Recommends: fp-compiler-$v:$a and a Description to match, so that
people finding it via `apt-file` (including `command-not-found`) will
get the right thing.)

There is no circular dependency - only the -common package has a
versioned -> nonversioned dependency. And the contents will be:

fp-compiler:$a : empty
fp-compiler-$v:$a : executable /usr/lib/fpc/$v/ppc$a
fp-compiler-driver-$v:$a : executable /usr/lib/fpc/$v/fpc, symlink
/usr/bin/fpc-$v and sometimes (via update-alternatives) /usr/bin/fpc
fp-compiler-config-$v:all : /etc/fpc/$v/{mkcfg,local}.cfg
fp-compiler-config-common:all : /etc/fpc/{debian,local}.cfg, *all*
/etc/fpc/$a/{target,local}.cfg and (via update-alternatives)
/etc/fpc.cfg

It would be possible to put the /etc/fpc/$a/{target,local}.cfg files
in yet *another* package, but IMO there's no value in it. (They are
unversioned so that can't go in fp-compiler:$a which might not be
installed if just fp-compiler-$v:$a is).

While it would *currently* be possible to make fp-compiler-config-$v
architecture-specific (since multi-arch allows overwriting files as
long as they are identical), that would prove to be a mistake once
"real" cross-compiler packages are added. By avoiding relying on this,
it becomes easier to transition from *:$a to *-$a packages in future.

All `Architecture: all` packages should be `Multi-Arch: foreign`.
All `Architecture: $a` packages should be `Multi-Arch: same` *except*
`fp-compiler-driver{,-$v}`, `fp-utils{,-$v}`, and `fp-ide{,-$v}` which
should be `Multi-Arch: foreign` since they only make sense on the
host. (The future fp-compiler{,-$v}-$a packages will also be
`Multi-Arch: foreign`).

-Ben

Bug#845498: [Pkg-pascal-devel] Bug#845498: Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

I got it completely working now! I did have to repack
binutils-{i586,x86-64}-linux-gnu though.

Tested that I can generate both i386 and aarch64 binaries, solely by
specifying `-P`. Still haven't actually tested linking with libc, for
that we'll need to do something nasty about /lib32/ (probably just
some ifdefs based on the *host* platform - need to extend the arch
tables for that)

For packaging, you'll almost certainly want to split up the
fp-compiler bits into 2-5 packages
(fp-compiler-{bin,driver,config,config-$fpc_target}). Note that the
new /etc/fpc/debian.cfg must be installed from the *unversioned*
package - which will require a "backwards" dependency
(fp-compiler-config-3.0.0 depends on fp-compiler-config-common).

Updated the GIST at the same URL:

https://gist.github.com/o11c/cf98115ba716ebdd1dc2cc75b290f321

Bug#846628: cross-binutils: Missing `Multi-Arch: foreign`, so not useful

[Ben Longbons]

Source: cross-binutils
Version: 2.25-8
Severity: important

Dear Maintainer,

For some reason, the binutils-{i586,x86-64}-linux-gnu packages are
missing missing the necessary `Multi-Arch: foreign` setting, so
they can't be used to fulfil cross-dependencies.

Most likely this source package should be dropped and they should be
enabled in src:binutils like the rest of the arches (which have correct
headers) - it's two versions newer anyway.


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

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)

Bug#845498: [Pkg-pascal-devel] Bug#845498: Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

Okay, I've got it *almost* working:
https://gist.github.com/o11c/cf98115ba716ebdd1dc2cc75b290f321

I'm still getting errors from update-alternatives in postinst, but I
*think* everything else is right - at least, things that weren't
completely wrong before (there are a lot of those).

I have SUCCESSFULLY produced 32-bit binaries on a 64-bit host, but
that doesn't prove the /etc/ stuff is right. Need to add testcases,
and also force linking with libc.

Hopefully this answers the various questions people have had, e.g.
about what we need to do about binutils.

There are a LOT of TODOs, referring to various bugs (or things) in
various packages (or things), in the script. I suggest you guys look
at them.

Oh, and I haven't tested phase3 with anything besides --dist=stretch.

I will be updating the gist, so remember to `git pull` before.

On Tue, Nov 29, 2016 at 11:55 AM, Abou Al Montacir
 wrote:
> Instead of writing a tool to hack all this, I'd propose you submit patches
> and join the maintain team.

I'd rather pull my own teeth out with a rusty spoon. Debian packaging
is beyond all doubts the worst I've ever played with - nearly entirely
due to the "in-source" rather than "out-of-source" nature of the
packaging (which is also extremely hostile to upstreams).

Compare e.g. The Fedora documentation [1] - it is *far* simpler for
newcomers, and this is *not* a matter of documentation. (I used to
mention Gentoo since that was my first, but that always makes people
get distracted by the totally-irrelevant fact that the Gentoo project
doesn't *ship* the binary packages). For that matter, even NixOS
packages[2], which live in an utterly alien environment, are easier to
get into than Debian packages.

[1]: 
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/sect-Packagers_Guide-Creating_a_Basic_Spec_File.html
[2]: https://nixos.org/nixpkgs/manual/

Bug#846184: binutils-mingw-w64: Inconsistent with other cross packages

[Ben Longbons]

On Tue, Nov 29, 2016 at 12:05 AM, Stephen Kitt  wrote:
> I wasn't aware of that, I thought all modern tools were capable of using
> triplet-prefixed tools. I'll add the symlinks... Just out of curiosity, do
> you have specific examples of non-C cross-compilers which fail currently?

I'm currently working on `fp-compiler`. From `fpc(1)`:

   Options concerning files and directories

   -exxx  tells  the  compiler that xxx is the directory where it can find
  the executables as (the assembler) and ld (the linker).

   -FDsame as -e.

(Of course, actually making it actually usable will require
fp-units-$triple packages too).

It's kind of similar to the justification for
/usr/lib/{compat,gold}-ld too - I remember when `-fuse-ld={gold,bfd}`
didn't exist yet but I wanted to test both ways so I had to use `gcc
-B`.

-Ben

Bug#846184: binutils-mingw-w64: Inconsistent with other cross packages

[Ben Longbons]

Package: binutils-mingw-w64
Version: 2.27.51.20161105-2+7.2
Severity: wishlist

Dear Maintainer,

To be consistent with other binutils-$cross packages:

* the packages should be named according to the triple
(binutils-i686-w64-mingw32 and binutils-x86-64-w64-mingw32 - note that
underscore is not valid in package names so it is replace with dash)

* Symlinks should be placed in /usr/$triple/bin
(This is important to support tools that only know how to look
for `ld` and `as` in another PATH, common among non-C cross-compilers)


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

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 binutils-mingw-w64 depends on:
ii  binutils-mingw-w64-i6862.27.51.20161105-2+7.2
ii  binutils-mingw-w64-x86-64  2.27.51.20161105-2+7.2

binutils-mingw-w64 recommends no packages.

binutils-mingw-w64 suggests no packages.

-- no debconf information

Bug#846182: reportbug: Wrong package version detected when it contains a +

[Ben Longbons]

Package: reportbug
Version: 6.6.6
Severity: normal

Dear Maintainer,

While reporting a bug against binutils-mingw-w64, `reportbug` claimed it
was out-of-date:


Getting status for binutils-mingw-w64...
Checking for newer versions at madison...

Your version (2.27.51.20161105-2+7.2) of binutils-mingw-w64 appears to be out 
of date.
The following newer release(s) are available in the Debian archive:
  stable: 5.2+deb8u1
  testing: 7.2
  unstable: 7.2


But from ,
the available versions should be:

oldstable: 2.22-8+deb7u2+2+deb7u1
stable: 2.25-5+5.2+deb8u1
testing: 2.27.51.20161105-2+7.2
unstable: 2.27.51.20161105-2+7.2


-- Package-specific info:
** Environment settings:
PAGER="less"
INTERFACE="text"

** /home/ben/.reportbugrc:
reportbug_version "5.1.1"
mode standard
ui text
email "brlongb...@gmail.com"
smtphost smtp.gmail.com:587
smtpuser "brlongb...@gmail.com"
smtptls

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

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 reportbug depends on:
ii  apt   1.3.1
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88~RC4-2
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC4-2
ii  file   1:5.29-1
ii  gnupg  2.1.16-2
ii  python-gtk22.24.0-5.1
pn  python-gtkspellcheck   
ii  python-urwid   1.3.1-2+b1
ii  python-vte 1:0.28.2-5+b1
ii  xdg-utils  1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.3.1
ii  file  1:5.29-1
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#845498: [Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

On Mon, Nov 28, 2016 at 12:19 AM, Abou Al Montacir
 wrote:
> For now you can use multi-arch to install fp-compiler

No, you can't (that was the first thing I thought of):
fp-compiler:i386 depends on binutils:i386 rather than
binutils-i586-linux-gnu, and binutils:i386 isn't multiarch
installable. You'd have to do a full cross chroot, currently.

But once the dependency part is fixed, /etc/fpc.cfg can `#INCLUDE
/etc/fpc/$FPCTARGET.cfg` and put `-e/usr/i586-linux-gnu/bin
-Fl/usr/lib/i386-linux-gnu -Fl/lib/i386-linux-gnu -Fl /usr/lib32
-Fl/lib32` in there (each of those .cfg files will have to be manually
written/installed based on the Debian arch (of the fp-compiler
package), the Debian triple (subdir of /usr/lib), the legacy libdir
(/lib32 - actually not sure if this is necessary or not anymore), the
GNU triple (of binutils), and the FPC target (for choice of the
filename)). Incidentally, managing /etc/fpc.cfg through
update-alternatives is a waste since it could be implemented as just
`#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4, an
appropriate upgrade path would need to be written).

The above is fairly trivial and will get you a multiarch "cross"
compiler, with /etc/ ready for real (non-multiarch fp-compiler (I
*think* the libc6-*-cross packages are only needed because of ld.so
conflicting. but fp-units-* are actually multiarch safe already,
they're just not marked as such - they put all their files in
/usr/lib/fpc/$fpcversion/{units,fpmkinst}/$FPCTARGET/ already)) ones.
Then it's just a SMOC to actually build real cross-compilers binary
packages from the Debian source package.

I should probably write a tool to hack-up what I've described above by
using `apt-get download` and extracting/modifying the .deb files.
Maybe test it on Jessie since it has backports to test multiple
*versions* too.

> then just use a shell script to call call the right FPC using qemu

The shell script is unnecessary if you install qemu-user-binfmt (or
qemu-user-static, which `Provides:` it).

-Ben

Bug#845504: [Pkg-pascal-devel] Bug#845504: /usr/bin/ppdep-3.0.0: Claims to understand conditional defines, but doesn't handle {$ELSE}

[Ben Longbons]

On Thu, Nov 24, 2016 at 9:45 PM, Michalis Kamburelis
 wrote:
> 2. The utility of "ppdep" for Pascal is limited anyway. Unlike in C,
> in Pascal the compiler already handles the dependencies (what unit
> should be recompiled when and in what order). So generating Makefiles
> with dependencies per-unit is usually not needed.

It's necessary to avoid race conditions if you have multiple programs
that use the same units. E.g. `texutil.{o,ppu}` get opened (with
`O_TRUNCATE`) multiple times, rather than using atomic renames (which
would still be duplicate work ... but fpc is fast anyway. Still bad if
the compiler fails and `make` hasn't had a chance to clean up) or
locking.

I refuse to use `.NOTPARALLEL:` out of principle.

I can live with the other limitations - IMHO reasonable code won't do
*too* much of that, at least for things that `ppdep` even needs to
worry about.

Thanks for the quick response,
-Ben

Bug#845504: /usr/bin/ppdep-3.0.0: Claims to understand conditional defines, but doesn't handle {$ELSE}

[Ben Longbons]

Package: fp-utils-3.0.0
Version: 3.0.0+dfsg-9
Severity: important
File: /usr/bin/ppdep-3.0.0

Dear Maintainer,


In the `gearhead` package, `ppdep gharena.pas` produces almost no
output, whereas `ppdep -dSDLMODE gharena.pas` produces plenty.

Relevant source snippet:

{$IFDEF SDLMODE}
uses gears,sdlgfx,arenahq,sdlmenus,randchar,navigate,sdlmap;
{$ELSE}
uses gears,congfx,arenahq,conmenus,randchar,navigate,context,mapedit;
{$ENDIF}

Expected output:
gharena: gharena.pas 
foo.ppu: foo.pp 

Actual output:
gharena: gharena.pas

Workaround:

{$IFNDEF SDLMODE}
{$DEFINE TUIMODE}
{$ENDIF}

{$IFDEF SDLMODE}
uses gears,sdlgfx,arenahq,sdlmenus,randchar,navigate,sdlmap;
{$ENDIF}
{$IFDEF TUIMODE}
uses gears,congfx,arenahq,conmenus,randchar,navigate,context,mapedit;
{$ENDIF}

... and so on, 269 more times. Assuming none of those {$ELSE}s is for
something "else" besides {$IFDEF SDLMODE}.


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

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 fp-utils-3.0.0 depends on:
ii  fpc-source-3.0.0  3.0.0+dfsg-9
ii  libc6 2.24-5

Versions of packages fp-utils-3.0.0 recommends:
ii  fp-compiler-3.0.0  3.0.0+dfsg-9

fp-utils-3.0.0 suggests no packages.

-- no debconf information

Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

Package: fp-compiler-3.0.0
Version: 3.0.0+dfsg-9
Severity: wishlist
File: /usr/bin/fpc-3.0.0

Dear Maintainer,

According to `fpc -help`,
-P  Set target CPU 
(arm,avr,i386,jvm,m68k,mips,mipsel,powerpc,powerpc64,sparc,x86_64)

However, if I try any of those besides the current CPU, I get:

Error: ppc386 can't be executed, error message: Failed to execute "ppc386", 
error code: 127

(note: while, multiarch would work for x86_64 -> i386, it won't work for
anything else, so you really do need a native ppc386 binary, etc)

You'll probably have to also tell it to use ${triple}-ld, etc.


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

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 fp-compiler-3.0.0 depends on:
ii  binutils   2.27.51.20161108-1
ii  debconf [debconf-2.0]  1.5.59
ii  fp-units-rtl-3.0.0 3.0.0+dfsg-9
ii  libc6  2.24-5

Versions of packages fp-compiler-3.0.0 recommends:
ii  fp-utils-3.0.0  3.0.0+dfsg-9

Versions of packages fp-compiler-3.0.0 suggests:
pn  fp-docs-3.0.0 
pn  mingw32-binutils  

-- debconf information excluded

Bug#845154: gearhead: Please apply the xterm-boxdrawing patch

[Ben Longbons]

Package: gearhead
Version: 1.302-2
Severity: wishlist

Dear Maintainer,

The upstream sources include a directory named 'xterm-boxdrawing',
which includes a patch to the Pascal standard library (thus why upstream
can't enable it by default, since vendoring the stdlib is just plain
evil).

Since the application is statically-linked, and fpc-source is already a
build-dep, there shouldn't be any problem applying it to this package.

Despite the name, the patch also fixes the irritating cursor-blinking
problem.


>From xterm-boxdrawing/README:

This directory contains a hack to allow linedrawing characters to be used on
Linux, both in the raw console and in an XTerm or PuTTY client.  It is
dependent on some modifications to the standard CRT library included with
FreePascal.

In addition, the CRT mods fix the cursor-off routines to use sequences
understood by XTerm, PuTTY and old versions of Linux, instead of sequences
specific to Linux.

These mods are specific to FPC version 3.0.0 on unix.

To use it:

1.  Obtain the files:
 fpc-3.0.0/packages/rtl-console/src/unix/crt.pp
 fpc-3.0.0/packages/rtl-console/src/inc/crth.inc
from the FreePascal sources.  Copy them into the the main gearhead
directory, alongside the existing *.pp files.

2. Apply the patch "crt.pp.diff" in this directory.

3. Copy the file "boxdraw.inc" in this directory to the main gearhead
directory, overwriting the original version.

4. Compile Gearhead normally.  The crt.pp in the current directory will
automatically be used instead of the standard version.


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

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 gearhead depends on:
ii  gearhead-data  1.302-2

gearhead recommends no packages.

Versions of packages gearhead suggests:
ii  gearhead-sdl  1.302-2

-- no debconf information

Bug#844091: pyqt5-examples: Could not load description. Ensure that the documentation for Qt is built.

[Ben Longbons]

Package: pyqt5-examples
Version: 5.7+dfsg-2
Severity: normal

Dear Maintainer,

Run /usr/share/doc/pyqt5-examples/examples/qtdemo/qtdemo.py

Click any category, then any example in that category.

Instead of seeing an overview of the example, it just gives an error.

Additionally, clicking on the "Documentation" link opens Qt Assistant
to a 404 page.

(Actually "Launch"ing the example does work, however).


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

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 pyqt5-examples depends on:
ii  libjs-jquery   3.1.1-1
ii  python3-pyqt5  5.7+dfsg-2

pyqt5-examples recommends no packages.

Versions of packages pyqt5-examples suggests:
pn  pyqt5-dev-tools 
ii  python3-pyqt5.qtmultimedia  5.7+dfsg-2
ii  python3-pyqt5.qtopengl  5.7+dfsg-2
ii  python3-pyqt5.qtquick   5.7+dfsg-2
ii  python3-pyqt5.qtsvg 5.7+dfsg-2
ii  qt5-doc 5.6.1-1
ii  qttools5-dev-tools  5.6.1-4

-- no debconf information

Bug#841150: openclonk: Segfault while loading game

[Ben Longbons]

Package: openclonk
Version: 7.0-4
Severity: normal

Dear Maintainer,

Every time I load any savegame from the first mission (The Raid), the game
crashes.

I have a coredump in case further information is needed.

(gdb) bt
#0  0x558cacdc in (anonymous namespace)::CompileFloat(StdCompiler*, 
float&) (pComp=0x7fffc9f0, f=@0x1c: ) at 
./src/lib/StdMesh.cpp:190
#1  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdMesh.cpp:229
#2  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(pComp=0x7fffc9f0, rStruct=) at ./src/lib/StdCompiler.h:319
#3  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:171
#4  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdAdaptors.h:80
#5  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:170
#6  0x558d24f6 in 
StdMeshInstance::AnimationNode::CompileFunc(StdCompiler*, StdMesh const*) 
(this=this@entry=0x622497c0, pComp=pComp@entry=0x7fffc9f0, 
Mesh=0x5ade45c0) at ./src/lib/StdMesh.cpp:889
#7  0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (pComp=0x7fffc9f0, this=) at 
./src/lib/StdAdaptors.h:446
#8  0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (rStruct=, this=0x7fffc9f0) at 
./src/lib/StdCompiler.h:170
#9  0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (rPar=@0x7fffc728: 0x5ade45c0, 
pComp=0x7fffc9f0, pStruct=) at ./src/lib/StdCompiler.h:346
#10 0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (adapt=@0x7fffc730: {
   = {
rpObj = @0x7fffc718, 
fAllowNull = true, 
szNaming = 0x55a7537e "AnimationNode"
  }, }, par=@0x7fffc728: 0x5ade45c0, 
pComp=0x7fffc9f0) at ./src/lib/StdAdaptors.h:622
#11 0x558d63c4 in 
StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, 
StdMesh const* const&) (pComp=pComp@entry=0x7fffc9f0, 
adapt=@0x7fffc730: {
   = {
rpObj = @0x7fffc718, 
fAllowNull = true, 
szNaming = 0x55a7537e "AnimationNode"
  }, }, par=@0x7fffc728: 0x5ade45c0) at 
./src/lib/StdAdaptors.h:609
#12 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) (p=@0x7fffc728: 
0x5ade45c0, pComp=0x7fffc9f0, this=0x7fffc730)
at ./src/lib/StdAdaptors.h:520
#13 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) (pComp=0x7fffc9f0, 
this=0x7fffc720) at ./src/lib/StdAdaptors.h:446
#14 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) (rStruct=@0x7fffc720: {
  rObj = @0x7fffc730, 
  Par = 0x5ade45c0
}, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:170
#15 0x558d33b6 in StdMeshInstance::CompileFunc(StdCompiler*, 
StdMeshInstance::AttachedMesh::Denumerator* (*)()) 
(this=this@entry=0x61875370, pComp=pComp@entry=0x7fffc9f0, 
Factory=Factory@entry=0x5599c8c0 
) at 
./src/lib/StdMesh.cpp:1568
#16 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdAdaptors.h:446
#17 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(pComp=0x7fffc9f0, rStruct=) at ./src/lib/StdCompiler.h:319
#18 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:171
#19 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(pComp=0x7fffc9f0, this=) at ./src/lib/StdAdaptors.h:80
#20 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(rStruct=, this=0x7fffc9f0) at ./src/lib/StdCompiler.h:170
#21 0x5599b631 in C4Object::CompileFunc(StdCompiler*, C4ValueNumbers*) 
(this=this@entry=0x6226f7a0, pComp=pComp@entry=0x7fffc9f0, 
numbers=0x7fffcbe0) at ./src/object/C4Object.cpp:2340
#22 0x559a2334 in StdPtrAdaptCompileFunc(StdCompiler*, StdPtrAdapt const&, C4ValueNumbers* 
const&) (pComp=0x7fffc9f0, this=)
at ./src/lib/StdAdaptors.h:446
#23 0x559a2334 in 

Bug#839259: W: Target Contents-deb-legacy (Contents-{amd64, i386, all}) is configured multiple times in /etc/apt/sources.list

[Ben Longbons]

Package: libapt-pkg5.0
Version: 1.3
Severity: normal

Dear Maintainer,

My /etc/apt/sources.list contains 'main' and 'contrib nonfree' on
separate lines. This results in constant spam whenever *any* step is
taken - it is particularly frustrating in aptitude, which requires them
to be interactively dismissed.

Testing with `apt-file search apt-file` is probably the simplest.

These errors are output:
### BEGIN ERRORS
W: Target Contents-deb-legacy (Contents-amd64) is configured multiple times in 
/etc/apt/sources.list:4 and /etc/apt/sources.list:9
W: Target Contents-deb-legacy (Contents-i386) is configured multiple times in 
/etc/apt/sources.list:4 and /etc/apt/sources.list:9
W: Target Contents-deb-legacy (Contents-all) is configured multiple times in 
/etc/apt/sources.list:4 and /etc/apt/sources.list:9
W: Target Contents-deb-legacy (Contents-amd64) is configured multiple times in 
/etc/apt/sources.list:4 and /etc/apt/sources.list:9
W: Target Contents-deb-legacy (Contents-i386) is configured multiple times in 
/etc/apt/sources.list:4 and /etc/apt/sources.list:9
W: Target Contents-deb-legacy (Contents-all) is configured multiple times in 
/etc/apt/sources.list:4 and /etc/apt/sources.list:9
### END ERRORS


The following is currently my sources.list (I also enable additional
foreign architectures sometimes, thus the comments):
### BEGIN sources.list
# Current distro: stretch

# get all arches for the `main` component
deb [ arch=amd64,i386 ] http://ftp.us.debian.org/debian stretch main
deb-src [ arch=amd64,i386 ] http://ftp.us.debian.org/debian stretch main
deb [ arch=amd64,i386 ] http://debug.mirrors.debian.org/debian-debug 
testing-debug main

# only fetch `non-free` and `contrib` on runnable arches
deb [ arch=amd64,i386 ] http://ftp.us.debian.org/debian stretch non-free 
contrib
deb-src [ arch=amd64,i386 ] http://ftp.us.debian.org/debian stretch non-free 
contrib

# get only runnable arches from /updates, but for all components
deb [ arch=amd64,i386 ] http://security.debian.org/ stretch/updates main 
non-free contrib
deb-src [ arch=amd64,i386 ] http://security.debian.org/ stretch/updates main 
non-free contrib

# get all arches from sid
deb [ arch=amd64,i386 ] http://ftp.us.debian.org/debian sid main
deb-src [ arch=amd64,i386 ] http://ftp.us.debian.org/debian sid main
deb [ arch=amd64,i386 ] http://debug.mirrors.debian.org/debian-debug 
sid-debug main
deb [ arch=x32 ] http://ftp.debian-ports.org/debian sid main

# get only runnable arches from experimental
deb [ arch=amd64,i386 ] http://ftp.us.debian.org/debian experimental main
deb-src [ arch=amd64,i386 ] http://ftp.us.debian.org/debian experimental main
### END sources.list


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

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 libapt-pkg5.0 depends on:
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.23-5
ii  libgcc1 1:6.1.1-11
ii  liblz4-10.0~r131-2
ii  liblzma55.1.1alpha+20120614-2.1
ii  libstdc++6  6.1.1-11
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages libapt-pkg5.0 recommends:
ii  apt  1.3

libapt-pkg5.0 suggests no packages.

-- no debconf information

Bug#830816: mpdris2: GLib.Error: ... The name org.freedesktop.Notifications was not provided by any .service files (2)

[Ben Longbons]

Notifications suddenly started working again yesterday. In the mean
time, I had edited the script to catch the exception and continue, so
at least the *controls* worked.

I use KDE and start it from SDDM - basically as vanilla as you can
get. I have noticed some KDE library packages getting upgraded lately
...

$ dpkg -l 
ii  dbus-x11   1.10.8-1 amd64simple interprocess messaging sys
ii  notification-d 3.20.0-1 amd64daemon for displaying passive pop
ii  plasma-workspa 4:5.6.5.1-1  amd64Plasma Workspace for KF5



On Mon, Jul 25, 2016 at 2:44 AM, Simon McVittie <s...@debian.org> wrote:
> On Mon, 11 Jul 2016 at 13:11:47 -0700, Ben Longbons wrote:
>> GLib.Error: g-dbus-error-quark: 
>> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
>> org.freedesktop.Notifications was not provided by any .service files (2)
>
> Which desktop environment are you using? (If you are not using a major
> desktop environment like GNOME/KDE/XFCE, please summarize how your
> graphical session starts, instead.)
>
> Do you have dbus-user-session installed?
>
> Do you have an implementation of o.fd.Notifications? (In no particular
> order: lxqt-notificationd, xfce4-notifyd, notify-osd, dunst,
> mate-notification-daemon, notification-daemon, cinnamon, gnome-shell,
> plasma-workspace or gnome-flashback.)
>
> mpdris2 should probably have a Recommends on notification-daemon to
> ensure that one of those is pulled in. It should perhaps also
> log-but-ignore errors communicating with the notification service.
>
> S

Bug#830816: mpdris2: GLib.Error: ... The name org.freedesktop.Notifications was not provided by any .service files (2)

[Ben Longbons]

Package: mpdris2
Version: 0.7+git20160206-1
Severity: normal

Dear Maintainer,

Suddenly, mpdris2 fails to start. Since normally mpdris2 just runs
constantly in the background, and I usually stay logged in, I'm not
sure how long this has been a problem.

2016-07-11 13:08:29,942 mpDris2 INFO: Using file:///home/ben/Music as music 
library path.
2016-07-11 13:08:29,942 mpDris2 INFO: Mutagen not available, covers in music 
files will be ignored.
2016-07-11 13:08:29,948 mpDris2 WARNING: Failed to connect to GNOME Settings 
Daemon. Media keys won't work.
Traceback (most recent call last):
  File "/usr/bin/mpDris2", line 1290, in 
mpd_wrapper.run()
  File "/usr/bin/mpDris2", line 275, in run
if self.my_connect():
  File "/usr/bin/mpDris2", line 342, in my_connect
self.timer_callback()
  File "/usr/bin/mpDris2", line 432, in timer_callback
self._update_properties(force=False)
  File "/usr/bin/mpDris2", line 703, in _update_properties
self.notify_about_track(new_meta, new_status['state'])
  File "/usr/bin/mpDris2", line 591, in notify_about_track
notification.notify(title, body, uri)
  File "/usr/bin/mpDris2", line 838, in notify
self._notification.show()
GLib.Error: g-dbus-error-quark: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files (2)


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

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 mpdris2 depends on:
ii  dbus 1.10.8-1
ii  python   2.7.11-2
ii  python-dbus  1.2.4-1
ii  python-gi3.20.1-1
ii  python-mpd   0.3.0-4

Versions of packages mpdris2 recommends:
ii  gir1.2-notify-0.7  0.7.6-2

Versions of packages mpdris2 suggests:
ii  mpd  0.19.16-1

-- no debconf information

Bug#829134: debootstrap: Changes needed to support unprivileged userns debootstrap

[Ben Longbons]

Package: debootstrap
Version: 1.0.81
Severity: wishlist
Tags: patch

Dear Maintainer,

Now that the kernel supports user_namespaces(7), it should be possible
to debootstrap in them. Some small changes are needed.

Configuration needed:
* Kernel 3.8 or later (3.11 recommended)
* Set the sysctl kernel.unprivileged_userns_clone to 1
(Debian-specific "temporary" patch from years ago).
* Install the `uidmap` package and add yourself to /etc/sub[ug]id
* Install the `lxc` package (for one helper binary only)
* Make sure the current directory is searchable by other.

I have attached the necessary changes as a wrapper script, but there
really should be some architectural changes:

* The `/usr/sbin/debootstrap` vs `/usr/share/debootstrap/functions`
split is quite painful. Move everything into one file and then
replace sbin/debootstrap with basically `source functions; main`.
* Satisfy `shellcheck`s errors and warnings, and suppress the rest.
* Beware that shellcheck currently does not catch `echo $(false)`.
* Make it possible to use more than one `--variant` at once somehow.
* Debootstrap is currently not idempotent - see the `rm dev...` hack.
* If you're in a new mount namespace, no need to `umount` at the end.


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

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 debootstrap depends on:
ii  wget  1.18-1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-6

debootstrap suggests no packages.

-- no debconf information
#!/bin/sh
# userns-debootstrap - debootstrap in a unprivileged new UID namespace
#
# Copyright (c) 2016 Ben Longbons
#
#Permission is hereby granted, free of charge, to any person obtaining
#a copy of this software and associated documentation files (the
#"Software"), to deal in the Software without restriction, including
#without limitation the rights to use, copy, modify, merge, publish,
#distribute, sublicense, and/or sell copies of the Software, and to
#permit persons to whom the Software is furnished to do so, subject to
#the following conditions:
#
#The above copyright notice and this permission notice shall be
#included in all copies or substantial portions of the Software.
#
#THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
#EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
#MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
#IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
#CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
#TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
#SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

# (This is the same license as debootstrap itself).

# This currently requires Debootstrap 1.0.76 or later,
# to avoid devices.tar.gz (see debian bug 571136).

# Note that, if everything works *correctly*, we `exec` rather than `exit`.
set -e
trap 'echo Failed during setup' EXIT
bailout()
{
local status="$?"
echo "Bailing out with status $status"
if test -z "$BASH"
then
echo 'For more debug info, run under bash (e.g. with --bash)'
enter_debug_shell
return
fi

echo "Last command: $BASH_COMMAND"
test -z "$debug_variables" || ( set -o posix; set; )
backtrace

enter_debug_shell
}

trap 'bailout' EXIT
if test -n "$BASH"
then
# bash doesn't set BASH_LINENO correctly for EXIT, so use ERR
set -E
# shellcheck disable=SC2039
trap 'bailout' ERR
trap 'echo Bug: irregular exit' EXIT
fi
umask 022

enter_debug_shell()
{
test -n "$debug_shell" || return
echo 'Entering debug shell!'
# If run e.g. from vim's :make, it tries to steal our stdio
exec "$debug_shell" <> /dev/tty 1>&0 2>&0
}

# shellcheck disable=SC2039
backtrace()
{
local skip_head=0 skip_tail=1
echo Backtrace:
for i in $(eval "echo {${skip_head}..$((${#BASH_LINENO[@]}-skip_tail-1))}")
do
echo "${BASH_SOURCE[i]}:${BASH_LINENO[i]}: error: ... from ${FUNCNAME[i+1]}"
done
}

dispatch()
{
phase=phase1

suite=
target=
mirror=
script=

: $suite $target $mirror $script

local arg

for arg
do
case "$arg" in
-h | --help)
usage
;;
--bash)
if test -z "$BASH"
   

Bug#828921: nethogs: cui.cpp:497: void do_refresh(): Assertion `pwuid != __null' failed.

[Ben Longbons]

Package: nethogs
Version: 0.8.1-1
Severity: important

Dear Maintainer,

Whenever I try to run nethogs, it just aborts.

Presumably this is because I have users with no name (because they're
from a separate user_namespace(7) and their name only makes sense for
the id within it).

At the very least `nethogs` should not crash. Possibly, it could also
look up the user *within* that namespace, though care would have to be
taken to avoid confusion with the current namespace's names.

Relevant bits:
/proc/$PID/uidmap (note that in the nested case, this is relative to its
parent - so I'm not sure it is feasible to use correctly)
/proc/$PID/ns/user (for use with setns(2) - needs to be done in a separate
process, but is relatively simple to use)
/proc/$PID/root (to look up /etc/ relative to - or just chroot)
nsenter(1), setns(2)
unshare(1), unshare(2)
subuid(5), newuidmap(1)

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

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 nethogs depends on:
ii  libc62.22-11
ii  libgcc1  1:6.1.1-7
ii  libncurses5  6.0+20160319-1
ii  libpcap0.8   1.7.4-2
ii  libstdc++6   6.1.1-7
ii  libtinfo56.0+20160319-1

nethogs recommends no packages.

nethogs suggests no packages.

-- no debconf information

Bug#828180: zsh: $RANDOM number generator is not reset for subshells

[Ben Longbons]

Package: zsh
Version: 5.2-5
Severity: normal

Dear Maintainer,

Zsh just repeats the same number when $RANDOM is requested in fresh
subshells. In general, this sort of bug is a security vulnerability,
though I'm not aware of anyone doing security-sensitive stuff in zsh.

bash handles this correctly in variables.c by checking
`subshell_environment && seeded_subshell != pid` on every call and
reseeding then; it would also be possible to use `pthread_atfork` (or,
since the forking is entirely within the main executable, just the
manual equivalent at the call site).

See also tests/varenv.sh in the bash source package.

Simple test case:

zsh -c 'for I in {0..9}; do ( echo $RANDOM ); done; echo $RANDOM; for I in 
{0..9}; do ( echo $RANDOM ); done'

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  VersionArchitecture Description
+++-=-==--===
ii  0install-core 2.10-2 amd64cross-distribution 
packaging system (non-GUI parts)
ii  cmus  2.7.1+git20160225-1+b1 amd64lightweight ncurses 
audio player
ii  curl  7.47.0-1   amd64command line tool for 
transferring data with URL syntax
ii  git-buildpackage  0.7.5  all  Suite to help with 
Debian packages in Git repositories
ii  mpv   0.14.0-1+b2amd64video player based on 
MPlayer/mplayer2
ii  pulseaudio8.0-2+b2   amd64PulseAudio sound 
server
ii  reprepro  4.17.1-1   amd64Debian package 
repository producer
ii  systemd   230-2  amd64system and service 
manager
ii  systemd-container 230-2  amd64systemd 
container/nspawn tools
ii  systemd-coredump  230-2  amd64tools for storing and 
retrieving coredumps
ii  udev  230-2  amd64/dev/ and hotplug 
management daemon
ii  vlc-nox   2.2.4-2amd64multimedia player and 
streamer (without X support)

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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 zsh depends on:
ii  dpkg1.18.7
ii  libc6   2.22-11
ii  libcap2 1:2.25-1
ii  libtinfo5   6.0+20160319-1
ii  zsh-common  5.2-5

Versions of packages zsh recommends:
ii  libncursesw5  6.0+20160319-1
ii  libpcre3  2:8.38-3.1

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information

Bug#828174: less: SGR attributes don't wrap across lines

[Ben Longbons]

Package: less
Version: 481-2.1
Severity: normal

Dear Maintainer,

Whenever an attribute is still active across multiple lines, it is reset at
the end of the first line instead of continuing.


I know there is a potential performance problem related to scrolling
*backwards* (since the last full-reset may be indefinitely behind), but
doing the right thing for forward motion should be pretty simple and
would still be valuable.


BEGIN script
#!/bin/bash
echo Attributes:
attr() {
printf '%-11s -> \e[%sm %-11s \n' "$3" "$1" "$3"
printf '%-11s %-11s \e[%sm <- %-11s %6s  %3s\e[m\n' "" "$3" "$2" "$3" 
"$1" "$2"
# The trailing \e[m is only to ensure a clean state for terminals that
# don't support the "restore single attribute" commands.
}
# commented attributes are not supported in xterm, and less disables
# itself completely when output is redirected, so I don't know how to
# test them.
attr 38:5:1 39 fg-colon256
attr 38\;5\;1 39 fg-semi256
attr 48:5:1 49 bg-colon256
attr 48\;5\;1 49 bg-semi256
attr 31 39 foreground
attr 41 49 background
attr 91 39 fg-bright
attr 101 49 bg-bright
attr 1 22 bold
attr 2 22 faint
attr 3 23 italic
#attr 20 23 fraktur
attr 4 24 underline
attr 21 24 double
attr 5 25 blink
#attr 6 25 rapid
attr 7 27 reverse
attr 8 28 conceal
attr 9 29 striked
#attr 11 10 font1
#attr 12 10 font2
#attr 13 10 font3
#attr 14 10 font4
#attr 15 10 font5
#attr 16 10 font6
#attr 17 10 font7
#attr 18 10 font8
#attr 19 10 font9
#attr 51 54 framed
#attr 52 54 circled
#attr 53 55 overline
#attr 60 65 right1
#attr 61 65 right2
#attr 62 65 left1
#attr 63 65 left2
#attr 64 65 stress


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

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 less depends on:
ii  debianutils  4.7
ii  libc62.22-11
ii  libtinfo56.0+20160319-1

less recommends no packages.

less suggests no packages.

-- no debconf information

Bug#819112: /usr/bin/plasmashell: Re: /usr/bin/plasmashell: Date not updated in all clocks.

[Ben Longbons]

Package: plasma-workspace
Version: 4:5.6.4-2
Followup-For: Bug #819112

Dear Maintainer,

After recent upgrades, my UTC clock just shows the date as a set of
black boxes. Which I suppose is *technically* better than inaccurate
information, but more significantly might point to where the actual bug
is - the date part appears to never be redrawn, unlike the time part.

-Ben

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

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 plasma-workspace depends on:
ii  dbus-x11 1.10.8-1
ii  frameworkintegration 5.22.0-1
ii  gdb  7.10-1.1
ii  kde-cli-tools4:5.6.4-1
ii  kded55.22.0-1
ii  kinit5.22.0-1
ii  kio  5.22.0-1
ii  libc62.22-11
ii  libcln6  1.3.4-1
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.1.1-4
ii  libgps22 3.16-2
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.22.0-2
ii  libkf5auth5  5.22.0-1
ii  libkf5baloo5 5.22.0-2
ii  libkf5bookmarks5 5.22.0-2
ii  libkf5completion55.22.0-1
ii  libkf5configcore55.22.0-1
ii  libkf5configgui5 5.22.0-1
ii  libkf5configwidgets5 5.22.0-1
ii  libkf5coreaddons55.22.0-1
ii  libkf5crash5 5.22.0-1
ii  libkf5dbusaddons55.22.0-1
ii  libkf5declarative5   5.22.0-1
ii  libkf5globalaccel-bin5.22.0-1
ii  libkf5globalaccel5   5.22.0-1
ii  libkf5guiaddons5 5.22.0-1
ii  libkf5i18n5  5.22.1-1
ii  libkf5iconthemes55.22.0-1
ii  libkf5idletime5  5.22.0-1
ii  libkf5itemviews5 5.22.0-1
ii  libkf5jobwidgets55.22.0-1
ii  libkf5js55.22.0-1
ii  libkf5jsembed5   5.22.0-1
ii  libkf5kdelibs4support5   5.22.0-2
ii  libkf5kiocore5   5.22.0-1
ii  libkf5kiofilewidgets55.22.0-1
ii  libkf5kiowidgets55.22.0-1
ii  libkf5networkmanagerqt6  5.22.0-2
ii  libkf5newstuff5  5.22.0-1
ii  libkf5notifications5 5.22.0-1
ii  libkf5notifyconfig5  5.22.0-1
ii  libkf5package5   5.22.0-1
ii  libkf5plasma55.22.0-1
ii  libkf5plasmaquick5   5.22.0-1
ii  libkf5quickaddons5   5.22.0-1
ii  libkf5runner55.22.0-1
ii  libkf5screen-bin 4:5.6.4-3
ii  libkf5screen74:5.6.4-3
ii  libkf5service-bin5.22.0-1
ii  libkf5service5   5.22.0-1
ii  libkf5solid5 5.22.0-1
ii  libkf5su55.22.0-1
ii  libkf5texteditor55.22.0-1
ii  libkf5textwidgets5   5.22.0-1
ii  libkf5wallet-bin 5.22.0-1
ii  libkf5wallet55.22.0-1
ii  libkf5waylandclient5 4:5.22.0-1
ii  libkf5widgetsaddons5 5.22.0-1
ii  libkf5windowsystem5  5.22.0-1
ii  libkf5xmlgui55.22.0-1
ii  libkf5xmlrpcclient5  5.22.0-1
ii  libkscreenlocker55.6.4-2
ii  libksgrd74:5.6.4-1
ii  libkworkspace5-5 4:5.6.4-2
ii  libphonon4qt5-4  4:4.9.0-2
ii  libplasma-geolocation-interface5 4:5.6.4-2
ii  libprocesscore7  4:5.6.4-1
ii  libprocessui74:5.6.4-1
ii  libqalculate5v5  0.9.7-9.1+b1
ii  libqt5core5a 5.5.1+dfsg-17
ii  libqt5dbus5  5.5.1+dfsg-17
ii  libqt5gui5   5.5.1+dfsg-17
ii  libqt5network5   5.5.1+dfsg-17
ii  libqt5qml5  

Bug#826969: gcc-6-cross: Provide cross-compilers for kfreebsd and hurd too

[Ben Longbons]

Source: gcc-6-cross
Severity: wishlist

Dear Maintainer,

Currently, only *-linux-* triples are being built, but Debian supports
non-Linux kernels. For completeness, please provide:

- i386-gnu
- i386-kfreebsd-gnu
- x86_64-kfreebsd-gnu

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

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#826533: figlet: Please split data out of the package so it can be used by toilet

[Ben Longbons]

Package: figlet
Version: 2.2.5-2
Severity: wishlist

Dear Maintainer,

Most packages have an arch-independent foo-data package even if it
*isn't* usable by other packages.


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

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 figlet depends on:
ii  libc6  2.22-9

figlet recommends no packages.

figlet suggests no packages.

-- no debconf information

Bug#825970: pypy: Please package pypy3 as well now

[Ben Longbons]

Package: pypy
Version: 5.1.2+dfsg-1
Severity: wishlist

Dear Maintainer,

Yesterday, the first alpha of PyPy3 v5.2 (supporting 3.3) was released.

While the actual release is still some time off, now would be a good
time to start getting the infrastructure ready, either in experimental
or in unstable-with-a-blocking-bug (the latter might be more friendly
for packages that wish to release versions for both cpython and pypy).

Note that upstream pypy3 is released as a separate product (and
thus likely source package) despite being in the same repository.

PyPy3 v5.2 is now much more mature than the previous v2.4 release
(which was released shortly after the same-numbered PyPy2 release - the
whatsnew and release files for PyPy2 are much more thorough and generally
still applicable), and I've been using snapshots happily for a while.

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

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 pypy depends on:
ii  dpkg  1.18.7
ii  libbz2-1.01.0.6-8
ii  libc6 2.22-9
ii  libexpat1 2.1.1-2
ii  libffi6   3.2.1-4
ii  libgdbm3  1.8.3-13.1
ii  libncurses5   6.0+20160319-1
ii  libsqlite3-0  3.13.0-1
ii  libssl1.0.2   1.0.2h-1
ii  libtinfo5 6.0+20160319-1
ii  pypy-lib  5.1.2+dfsg-1
ii  zlib1g1:1.2.8.dfsg-2+b1

pypy recommends no packages.

Versions of packages pypy suggests:
ii  pypy-doc  5.1.2+dfsg-1
pn  pypy-tk   

-- no debconf information

Bug#798401: gdb-python2 does not actually link to python2, but python3

[Ben Longbons]

On Sun, May 29, 2016 at 1:59 AM, Hector Oron  wrote:
> Please let me know your gdb-python2 use case, that'd be quite helpful.

I certainly prefer the python3 version most of the time - by this
point, the infelicities of python3 are well understood and fewer in
number than those of python2.

However, remember that it is (to Debian) an RC bug to ship gdb python
scripts that are not compatible with both python2 and python3, so
being able to quickly test both is very important. And outside of
Debian, I need to ship scripts that work with distros that don't have
a python3 gdb. Yes, there's CI, but anything that doesn't get caught
until that late takes a longer cycle to fix.

Ideally, this *should* have been done for Jessie, but instead it got
stuck only with the python2 version instead of allowing both. There
*must* be at least one stable release that supports both; after that
the python2 variant can be removed.

-Ben

Bug#798401: gdb-python2 does not actually link to python2, but python3

[Ben Longbons]

Thanks, is there any chance you could look at the related-but-wishlist
bug 798405 while you have this package's debian/rules in your brain's
cache?

-Ben

On Sat, May 28, 2016 at 9:50 AM, Andreas Bombe <a...@debian.org> wrote:
> tags 798401 + patch
> thanks
>
> On Tue, Sep 08, 2015 at 12:59:06PM -0700, Ben Longbons wrote:
>> The gdb-python2 package does not actually contain a version of gdb
>> linked to python2. Rather, it is a byte-for-byte identical copy of the
>> /usr/bin/gdb shipped in the gdb package, which links to python3.
>>
>> I noticed that gdb-python2 has "Depends: libpython3.4", I presume this
>> is automatic from the list of linked shared libs.
>
> I have verified on snapshot.debian.org that gdb-python2 has been broken
> since it was introduced. Basically the python2 linked version gets built
> and then ignored. There were more problems such as files missing in
> gdb-python2.
>
> I have fixed these in the attached patch and will shortly upload a NMU
> with this fix to DELAYED/5-day.

Bug#825325: firefox-esr: Firefox sometimes uses a bold font when it shouldn't

[Ben Longbons]

Package: firefox-esr
Version: 45.1.1esr-1+b1
Severity: normal

Dear Maintainer,

After installing some new fonts, Firefox now displays most web pages in
bold - particularly, any site that requests "Arial".

This is *not* reproduced when I call font-config directly, so Firefox
must be doing something funky.

The package `fonts-arkpandora` contains Aerial, which is the highest
priority Arial--compatible font available in Debian. If I call
`fc-match Arial`, it correctly returns the "Regular" variant of the
font. However, Firefox is choosing the "Bold" variant for some reason.

If I remove /etc/fonts/conf.d/61-arkpandora.conf then Firefox chooses
the next option, Arimo, and correctly chooses the non-Bold variant.

I have reproduced this all with a fresh firefox profile
(firefox -no-remote -P).

-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: HTTPS-Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org
Status: enabled

Name: It's All Text!
Location: ${PROFILE_EXTENSIONS}/itsallt...@docwhat.gerf.org
Status: enabled

Name: Reddit Enhancement Suite
Location: ${PROFILE_EXTENSIONS}/jid1-xufzosoflzs...@jetpack.xpi
Status: enabled

Name: Shumway
Location: ${PROFILE_EXTENSIONS}/shum...@research.mozilla.org
Status: app-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: xkcd #1288: Substitutions (Cloud To Butt Fork)
Location: ${PROFILE_EXTENSIONS}/substituti...@github.com.xpi
Status: user-disabled

-- Plugins information

-- Addons package information
ii  firefox-esr45.1.1esr-1+b1 amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)

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

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 firefox-esr depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.4
ii  libasound21.1.0-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-9
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-4
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.30-1.1
ii  libhunspell-1.4-0 1.4.1-2
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.23-2
ii  libpango-1.0-01.40.1-1
ii  libsqlite3-0  3.12.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-4
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.11-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages firefox-esr recommends:
ii  gstreamer1.0-libav 1.8.1-1
ii  gstreamer1.0-plugins-good  1.8.1-1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-3
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.13.2+dfsg-5
pn  mozplugger 

-- no debconf information

Bug#825154: apt-cacher-ng: please keep running during upgrades

[Ben Longbons]

Package: apt-cacher-ng
Version: 0.9.2-1
Severity: wishlist

Dear Maintainer,

Currently, apt-cacher-ng is stopped during `prerm` and started during
`postinst`.

For many daemons, downtime is acceptable since they are only used by the
local system, but proxies are designed for use by *other* systems, so
it would be much nicer if apt-cacher-ng would do *nothing* during
`prerm` and do a *restart* during `postinst`, in `upgrade` mode.

This will require carefully thinking about a lot of edge cases, but
there can be a *long* time between the `prerm` and the `postinst` if
there is more than a handful of packages being upgraded at once.

(remember that `dpkg` must call `fsync` a bazillion times in order to
not lose data, and `fsync` is extremely slow on modern filesystems)


Partial Workaround: when you notice an upgrade to apt-cacher-ng is
available, install *only* that first so it avoids all the time spent on
other packages.


-- Package-specific info:

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

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 apt-cacher-ng depends on:
ii  adduser3.114
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.7
ii  init-system-helpers1.33
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.22-9
ii  libgcc11:6.1.1-3
ii  liblzma5   5.1.1alpha+20120614-2.1
ii  libssl1.0.21.0.2h-1
ii  libstdc++6 6.1.1-3
ii  libsystemd0229-6
ii  libwrap0   7.6.q-25
ii  zlib1g 1:1.2.8.dfsg-2+b1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.6.32~rc+dfsg-1
pn  doc-base  
ii  libfuse2  2.9.6-1

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
u'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/gentargetmode: Set up now and update later
* apt-cacher-ng/tunnelenable: false
* apt-cacher-ng/cachedir:
* apt-cacher-ng/port: keep
* apt-cacher-ng/bindaddress: localhost
* apt-cacher-ng/proxy: keep

Bug#824608: RFP: tis-interpreter -- An interpreter for finding subtle bugs in programs written in standard C

[Ben Longbons]

Package: wnpp
Severity: wishlist

* Package name: tis-interpreter
  Version : Magnesium-20151002+dev
  Upstream Author : Pascal Cuoq 
* URL : https://github.com/TrustInSoft/tis-interpreter
* License : GPL, LGPL, and modified QPL
  Programming Lang: OCaml
  Description : An interpreter for finding subtle bugs in programs written 
in standard C

Based on the frama-c package, but actually *runs* the code.

Bug#822651: linux-image-4.5.0-1-amd64: Spews into /dev/kmsg, causing unresponsive journald

[Ben Longbons]

Package: src:linux
Version: 4.5.1-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Apologies for not following the instructions to run the kernel while
reporting the bug, but the system was barely responsive enough for me to
extract any info.

Whenever my system is started with the 4.5 kernel, systemd-journald uses
about 120% CPU and still complains about dropping messages.

The 4.4 kernel works properly.

I managed to get coredumps of journald every 10 seconds for the whole
3-minute period it was allowed to run, but I doubt it will be useful
given the `dmesg` output.

-- Package-specific info:
** Kernel log: (manually saved from previous boot, limited lines because
just running `dmesg` would never stop).
[ 1686.225851] ACPI Error: No handler or method for GPE 13, disabling event 
(20160108/evgpe-790)
[ 1686.226059] ACPI Error: No handler or method for GPE 11, disabling event 
(20160108/evgpe-790)
[ 1686.226270] ACPI Error: No handler or method for GPE 11, disabling event 
(20160108/evgpe-790)
[ 1686.226289] ACPI Error: No handler or method for GPE 13, disabling event 
(20160108/evgpe-790)
[ 1686.226308] ACPI Error: No handler or method for GPE 15, disabling event 
(20160108/evgpe-790)
[ 1686.226317] ACPI Error: No handler or method for GPE 16, disabling event 
(20160108/evgpe-790)
[ 1686.226327] ACPI Error: No handler or method for GPE 17, disabling event 
(20160108/evgpe-790)
[ 1686.226346] ACPI Error: No handler or method for GPE 00, disabling event 
(20160108/evgpe-790)
[ 1686.226355] ACPI Error: No handler or method for GPE 01, disabling event 
(20160108/evgpe-790)
[ 1686.226364] ACPI Error: No handler or method for GPE 02, disabling event 
(20160108/evgpe-790)
[ 1686.226383] ACPI Error: No handler or method for GPE 04, disabling event 
(20160108/evgpe-790)
[ 1686.226401] ACPI Error: No handler or method for GPE 06, disabling event 
(20160108/evgpe-790)
[ 1686.226409] ACPI Error: No handler or method for GPE 07, disabling event 
(20160108/evgpe-790)
[ 1686.226427] ACPI Error: No handler or method for GPE 11, disabling event 
(20160108/evgpe-790)
[ 1686.226437] ACPI Error: No handler or method for GPE 12, disabling event 
(20160108/evgpe-790)
[ 1686.226456] ACPI Error: No handler or method for GPE 14, disabling event 
(20160108/evgpe-790)
[ 1686.226465] ACPI Error: No handler or method for GPE 15, disabling event 
(20160108/evgpe-790)
[ 1686.226473] ACPI Error: No handler or method for GPE 16, disabling event 
(20160108/evgpe-790)
[ 1686.226505] ACPI Error: No handler or method for GPE 00, disabling event 
(20160108/evgpe-790)
[ 1686.226514] ACPI Error: No handler or method for GPE 01, disabling event 
(20160108/evgpe-790)
[ 1686.226521] ACPI Error: No handler or method for GPE 02, disabling event 
(20160108/evgpe-790)
[ 1686.226528] ACPI Error: No handler or method for GPE 03, disabling event 
(20160108/evgpe-790)
[ 1686.226535] ACPI Error: No handler or method for GPE 04, disabling event 
(20160108/evgpe-790)
[ 1686.226555] ACPI Error: No handler or method for GPE 07, disabling event 
(20160108/evgpe-790)
[ 1686.226572] ACPI Error: No handler or method for GPE 11, disabling event 
(20160108/evgpe-790)
[ 1686.226587] ACPI Error: No handler or method for GPE 13, disabling event 
(20160108/evgpe-790)
[ 1686.226611] ACPI Error: No handler or method for GPE 16, disabling event 
(20160108/evgpe-790)
[ 1686.226639] ACPI Error: No handler or method for GPE 00, disabling event 
(20160108/evgpe-790)
[ 1686.226679] ACPI Error: No handler or method for GPE 04, disabling event 
(20160108/evgpe-790)
[ 1686.227005] ACPI Error: No handler or method for GPE 11, disabling event 
(20160108/evgpe-790)
[ 1686.227014] ACPI Error: No handler or method for GPE 12, disabling event 
(20160108/evgpe-790)
[ 1686.227022] ACPI Error: No handler or method for GPE 13, disabling event 
(20160108/evgpe-790)
[ 1686.227031] ACPI Error: No handler or method for GPE 14, disabling event 
(20160108/evgpe-790)
[ 1686.227051] ACPI Error: No handler or method for GPE 16, disabling event 
(20160108/evgpe-790)
[ 1686.227060] ACPI Error: No handler or method for GPE 17, disabling event 
(20160108/evgpe-790)
[ 1686.227082] ACPI Error: No handler or method for GPE 00, disabling event 
(20160108/evgpe-790)
[ 1686.227091] ACPI Error: No handler or method for GPE 01, disabling event 
(20160108/evgpe-790)
[ 1686.227098] ACPI Error: No handler or method for GPE 02, disabling event 
(20160108/evgpe-790)
[ 1686.227105] ACPI Error: No handler or method for GPE 03, disabling event 
(20160108/evgpe-790)
[ 1686.227125] ACPI Error: No handler or method for GPE 06, disabling event 
(20160108/evgpe-790)
[ 1686.227131] ACPI Error: No handler or method for GPE 07, disabling event 
(20160108/evgpe-790)
[ 1686.227148] ACPI Error: No handler or method for GPE 11, disabling event 
(20160108/evgpe-790)
[ 1686.227155] ACPI Error: No handler or method for GPE 12, disabling event 
(20160108/evgpe-790)
[ 1686.227171] ACPI Error: No handler 

Bug#780173: valgrind: ignores compressed debug sections (default for -dbg built by debhelper in compat v9)

[Ben Longbons]

Upstream fixed.

Bug#810898: apt: "apt-get update" (1.2) very slow with compressed indices and debtags

[Ben Longbons]

Package: debtags
Version: 2.0.2
Followup-For: Bug #810898

Dear Maintainer,

Perhaps just add a '&' so that the (unimportant) debtags can run
asychronously and the main apt-get can finish.

Perhaps in the long run, apt should have some general machinery for this?

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

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 debtags depends on:
ii  python3-apt 1.1.0~beta2
ii  python3-debian  0.1.27
pn  python3:any 

debtags recommends no packages.

Versions of packages debtags suggests:
pn  tagcoll  

-- no debconf information

Bug#821059: gawk: Please don't ship development man pages in the main package.

[Ben Longbons]

Package: gawk
Version: 1:4.1.3+dfsg-0.1
Severity: normal

Dear Maintainer,

There are a lot of reasons to have an awk interpreter. That doesn't mean I
want documentation of awk functions interfering with ordinary use of
man.

It's bad enough that there are a few pages that collide between
sections 1/8 and sections 2/3 without completely irrelevant additions.

Note that perl sidesteps the problem by having pages that mostly start
with a capital and contain a double-colon.


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

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 gawk depends on:
ii  libc6 2.22-6
ii  libgmp10  2:6.1.0+dfsg-2
ii  libmpfr4  3.1.4-1
ii  libreadline6  6.3-8+b4
ii  libsigsegv2   2.10-5

gawk recommends no packages.

Versions of packages gawk suggests:
pn  gawk-doc  

-- no debconf information

Bug#820935: fakeroot-ng: Missing "Provides: fakeroot"

[Ben Longbons]

Package: fakeroot-ng
Version: 0.18-4+b1
Severity: normal

Dear Maintainer,

This package includes `update-alternatives` support for
/usr/bin/fakeroot, but does not include the necessary `Provides:` line,
so it is impossible to install any package that `Depends: fakeroot`s
using only fakeroot-ng.


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

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 fakeroot-ng depends on:
ii  libc6   2.22-5
ii  libgcc1 1:5.3.1-13
ii  libstdc++6  5.3.1-13

fakeroot-ng recommends no packages.

fakeroot-ng suggests no packages.

-- no debconf information

Bug#820534: command-not-found: Ship apt config to update automatically

[Ben Longbons]

Package: command-not-found
Version: 0.2.38-3
Severity: wishlist

Dear Maintainer,

Now that `apt-file update` is included as part of `apt update`, the
standard config hook `APT::Update::Post-Invoke-Success` provides a simple
way to invoke `update-command-not-found` at the appropriate time
without either user intervention or a cronjob.

This obsoletes bug #578523


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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.0
ii  lsb-release  9.20160110
ii  python-gdbm  2.7.11-2
pn  python:any   

command-not-found recommends no packages.

command-not-found suggests no packages.

-- no debconf information

Bug#820533: appstream: Icons 64x64 is refetched in full on every change

[Ben Longbons]

Package: appstream
Version: 0.9.3-1
Severity: normal

Dear Maintainer,

Every time `aptitude update` is run, the complete tarball of icons
is fetched instead of using a tiny diff-index like everything else.

I assume there is some difficulty with non-text files, but this is not
very nice.


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

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

Versions of packages appstream depends on:
ii  libappstream30.9.3-1
ii  libc62.22-5
ii  libglib2.0-0 2.48.0-1
ii  libprotobuf-lite9v5  2.6.1-1.3
ii  libxapian22v51.2.22-3
ii  libxml2  2.9.3+dfsg1-1
ii  libyaml-0-2  0.1.6-3

appstream recommends no packages.

appstream suggests no packages.

-- no debconf information

Bug#819762: clang: -shared-libasan is unusable

[Ben Longbons]

Package: clang
Version: 1:3.6-33
Severity: normal

Dear Maintainer,

With the latest available versions of clang-3.{5..9}
( 1:3.5.2-3 1:3.6.2-3 1:3.7.1-2 1:3.8-2 1:3.9~svn262954-1 )
it is impossible to build and run programs using the shared version
of libasan.

For 3.5 through 3.7, the error is at link time:

/usr/bin/x86_64-linux-gnu-ld.bfd.real: cannot find 
/usr/lib/llvm-3.5/bin/../lib/clang/3.5.2/lib/linux/libclang_rt.asan-preinit-x86_64.a:
 No such file or directory
/usr/bin/x86_64-linux-gnu-ld.bfd.real: cannot find 
/usr/lib/llvm-3.5/bin/../lib/clang/3.5.2/lib/linux/libclang_rt.asan-x86_64.so: 
No such file or directory

The debian packaging appears to simply not include the shared versions
of the files. Since these are older versions, it may not be worth fixing.

For 3.8 and 3.9, the error is at load time:

libclang_rt.asan-x86_64.so => not found

exporting LD_LIBRARY_PATH works, but is not .

Among other things, this makes it impossible to use ASAN with shared
libraries, though there are reasons to want shared ASAN for binaries too.

Additionally, `-print-file-name=libasan.so` should do the right thing
like it does for GCC, to avoid both clang-specific behavior *and* trying
to guess the right architecture for the current set of CC and CFLAGS.

Particularly, for shared libraries, it is expected that you can do:
LD_PRELOAD=$(${CC} ${CFLAGS} -print-file-name=libasan.so):$LD_PRELOAD

# BEGIN TEST SCRIPT
#!/bin/bash

# ASAN is available since CLANG 3.1 and since GCC 4.8
# To test with a single version, do something like:
# LD_LIBRARY_PATH=/usr/lib/llvm-3.8/lib/clang/3.8.0/lib/linux/ CC=clang-3.8 
./test.sh

ALL_VERSIONS=$(echo gcc-4.{8..9} gcc-{5..6} clang-3.{1..9})

for CC in ${CC:-${ALL_VERSIONS}}
do
CFLAGS=-fsanitize=address
if [ "${CC}" != "${CC#clang}" ]
then
CFLAGS="$CFLAGS -shared-libasan"
fi
if ! ${CC} --version &> /dev/null
then
echo ${CC} is not installed.
continue
fi
if ! echo 'int main(){}' | ${CC} ${CFLAGS} -x c - &> /dev/null
then
echo ${CC} failed to compile/link the program.
continue
fi
if ldd a.out | grep -q 'not found'
then
echo ${CC} failed to create a loadable binary.
continue
fi
ACTUAL_ASAN=$(ldd a.out | grep asan | sed 's/.*=> *//;s/ *(.*) *//')
if ! DECLARED_ASAN=$(${CC} ${CFLAGS} -print-file-name=libasan.so 
2>/dev/null)
then
echo ${CC} failed to print filename.
continue
fi
if [ "$(realpath ${ACTUAL_ASAN})" != "$(realpath ${DECLARED_ASAN})" ]
then
echo ${CC} printed a different version than it actually used.
continue
fi
echo ${CC} is okay!
done
# END TEST SCRIPT

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

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

Versions of packages clang depends on:
ii  clang-3.6  1:3.6.2-3

clang recommends no packages.

clang suggests no packages.

-- no debconf information

Bug#819112: /usr/bin/plasmashell: Date not updated in all clocks.

[Ben Longbons]

Package: plasma-workspace
Version: 4:5.4.3-2
Severity: minor
File: /usr/bin/plasmashell

Dear Maintainer,

I add two clock widgets to my taskbar: one in local time and one in UTC.

However, while the *time* updates in both widgets, the date only gets
updated in the one that shows local time. The UTC clock sticks to the
date from the time Plasma started (or the time the widget's "show date?"
option was turned on).

I only noticed this a day or so ago, at which point the UTC clock was
showing the date for about a week ago (likely the last time either
plasma or kwin crashed).

Due to plasmashell's single-process architecture, it is difficult to
figure out which parts are responsible for anything (such as this
unresponsiveness or the excessive CPU usage I reported earlier).


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.8-1
ii  frameworkintegration 5.16.0-1
ii  gdb  7.10-1+b1
ii  kactivities  5.16.0-1
ii  kde-cli-tools4:5.4.3-1
ii  kded55.16.0-1
ii  kinit5.16.0-1
ii  kio  5.16.0-1
ii  libc62.22-3
ii  libcln6  1.3.4-1
ii  libdbusmenu-qt5-20.9.3+15.10.20150604-1
ii  libgcc1  1:5.3.1-11
ii  libgps22 3.15-2
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.16.0-1
ii  libkf5auth5  5.16.0-1
ii  libkf5baloo5 5.16.0-1
ii  libkf5bookmarks5 5.16.0-1
ii  libkf5completion55.16.0-1
ii  libkf5configcore55.16.0-1
ii  libkf5configgui5 5.16.0-1
ii  libkf5configwidgets5 5.16.0-1
ii  libkf5coreaddons55.16.0-1
ii  libkf5crash5 5.16.0-1
ii  libkf5dbusaddons55.16.0-1
ii  libkf5declarative5   5.16.0-1
ii  libkf5globalaccel-bin5.16.0-1
ii  libkf5globalaccel5   5.16.0-1
ii  libkf5guiaddons5 5.16.0-1
ii  libkf5i18n5  5.16.0-1
ii  libkf5iconthemes55.16.0-1
ii  libkf5idletime5  5.16.0-1
ii  libkf5itemviews5 5.16.0-1
ii  libkf5jobwidgets55.16.0-1
ii  libkf5js55.16.0-1
ii  libkf5jsembed5   5.16.0-1
ii  libkf5kdelibs4support5   5.16.0-1
ii  libkf5kiocore5   5.16.0-1
ii  libkf5kiofilewidgets55.16.0-1
ii  libkf5kiowidgets55.16.0-1
ii  libkf5networkmanagerqt6  5.16.0-1
ii  libkf5newstuff5  5.16.0-1
ii  libkf5notifications5 5.16.0-1
ii  libkf5notifyconfig5  5.16.0-1
ii  libkf5package5   5.16.0-1
ii  libkf5plasma55.16.0-1
ii  libkf5plasmaquick5   5.16.0-1
ii  libkf5quickaddons5   5.16.0-1
ii  libkf5runner55.16.0-1
ii  libkf5screen64:5.4.3-1
ii  libkf5service-bin5.16.0-1
ii  libkf5service5   5.16.0-1
ii  libkf5solid5 5.16.0-1
ii  libkf5su55.16.0-1
ii  libkf5texteditor55.16.0-1
ii  libkf5textwidgets5   5.16.0-1
ii  libkf5wallet-bin 5.16.0-1
ii  libkf5wallet55.16.0-1
ii  libkf5waylandclient5 4:5.4.3-1
ii  libkf5waylandserver5 4:5.4.3-1
ii  libkf5webkit55.16.0-1
ii  libkf5widgetsaddons5 5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libkf5xmlgui55.16.0-1
ii  libkf5xmlrpcclient5  5.16.0-1
ii  libksgrd74:5.4.3-1
ii  libkworkspace5-5 4:5.4.3-2
ii  libpam0g 1.1.8-3.2
ii  libphonon4qt5-4  4:4.8.3-2

Bug#818336: linux-image-4.3.0-1-amd64: `ulimit -c` not respected when kernel.core_pattern is a pipe

[Ben Longbons]

Package: src:linux
Version: 4.3.5-1
Severity: normal

Dear Maintainer,

When the sysctl option kernel.core_pattern is a pipe (for example, the
default configuration on systemd-based systems), then `ulimit -c` is not
respected.

If the faulting process has excessive virtual memory usage (for example,
if it is running under a memory debugger such as AddressSanitizer),
the limit set by `ulimit -c` is not respected. Instead, the process will
be launched and max out the CPU and render the system nearly
unresponsive (despite the fact that I have 4 cores).

This essentially makes asan unusable, since when I'm debugging,
segfaults and calls to abort() are quite common.

Reproducer:
# first set kernel.core_pattern, e.g. by installing systemd-coredump
# then start `top` in another terminal to see CPU usage
export LD_PRELOAD=$(gcc -print-file-name=libasan.so):${LD_PRELOAD}
dash -c 'ulimit -c 0; set -m; sleep 99 & kill -ABRT %1'


-- Package-specific info:
** Version:
Linux version 4.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160121 (Debian 5.3.1-7) ) #1 SMP Debian 4.3.5-1 (2016-02-06)

** Command line:
BOOT_IMAGE=/vmlinuz-4.3.0-1-amd64 root=/dev/mapper/joyplim-root ro 
syscall.x32=y quiet splash

** Not tainted

** Kernel log:
[335206.565353] Broke affinity for irq 16
[335206.566449] smpboot: CPU 1 is now offline
[335206.578569] Broke affinity for irq 16
[335206.578609] Broke affinity for irq 32
[335206.580058] smpboot: CPU 2 is now offline
[335206.591867] Broke affinity for irq 1
[335206.591875] Broke affinity for irq 9
[335206.591880] Broke affinity for irq 12
[335206.591884] Broke affinity for irq 16
[335206.591889] Broke affinity for irq 17
[335206.591916] Broke affinity for irq 30
[335206.591919] Broke affinity for irq 32
[335206.592948] smpboot: CPU 3 is now offline
[335206.608241] ACPI: Low-level resume complete
[335206.608356] ACPI : EC: EC started
[335206.608357] PM: Restoring platform NVS memory
[335206.608633] LVT offset 0 assigned for vector 0x400
[335206.608711] [Firmware Bug]: cpu 0, try to use APIC500 (LVT offset 0) for 
vector 0xf9, but the register is already in use for vector 0x400 on another cpu
[335206.608713] [Firmware Bug]: cpu 0, failed to setup threshold interrupt for 
bank 4, block 0 (MSR0413=0xc100)
[335206.608715] [Firmware Bug]: cpu 0, try to use APIC500 (LVT offset 0) for 
vector 0xf9, but the register is already in use for vector 0x400 on another cpu
[335206.608716] [Firmware Bug]: cpu 0, failed to setup threshold interrupt for 
bank 4, block 1 (MSRC408=0xc100)
[335206.608815] Enabling non-boot CPUs ...
[335206.628325] x86: Booting SMP configuration:
[335206.628327] smpboot: Booting Node 0 Processor 1 APIC 0x11
[335206.631020]  cache: parent cpu1 should not be sleeping
[335206.631429] CPU1 is up
[335206.648514] smpboot: Booting Node 0 Processor 2 APIC 0x12
[335206.651009]  cache: parent cpu2 should not be sleeping
[335206.651584] CPU2 is up
[335206.668705] smpboot: Booting Node 0 Processor 3 APIC 0x13
[335206.671384]  cache: parent cpu3 should not be sleeping
[335206.671943] CPU3 is up
[335206.672989] ACPI: Waking up from system sleep state S3
[335207.733883] ohci-pci :00:12.0: System wakeup disabled by ACPI
[335207.733913] ohci-pci :00:13.0: System wakeup disabled by ACPI
[335207.751688] ehci-pci :00:12.2: System wakeup disabled by ACPI
[335207.753351] xhci_hcd :00:10.0: System wakeup disabled by ACPI
[335207.754109] ehci-pci :00:13.2: System wakeup disabled by ACPI
[335207.754395] PM: noirq resume of devices complete after 20.988 msecs
[335207.754895] PM: early resume of devices complete after 0.427 msecs
[335207.755205] ath: phy0: ASPM enabled: 0x43
[335207.755263] r8169 :03:00.0: System wakeup disabled by ACPI
[335207.761535] sd 0:0:0:0: [sda] Starting disk
[335207.762021] [drm] PCIE GART of 1024M enabled (table at 0x002E8000).
[335207.762177] radeon :00:01.0: WB enabled
[335207.762181] radeon :00:01.0: fence driver on ring 0 use gpu addr 
0x3c00 and cpu addr 0x88003557ec00
[335207.762912] radeon :00:01.0: fence driver on ring 5 use gpu addr 
0x00075a18 and cpu addr 0xc90001035a18
[335207.782961] radeon :00:01.0: fence driver on ring 6 use gpu addr 
0x3c18 and cpu addr 0x88003557ec18
[335207.782963] radeon :00:01.0: fence driver on ring 7 use gpu addr 
0x3c1c and cpu addr 0x88003557ec1c
[335207.782965] radeon :00:01.0: fence driver on ring 1 use gpu addr 
0x3c04 and cpu addr 0x88003557ec04
[335207.782967] radeon :00:01.0: fence driver on ring 2 use gpu addr 
0x3c08 and cpu addr 0x88003557ec08
[335207.782969] radeon :00:01.0: fence driver on ring 3 use gpu addr 
0x3c0c and cpu addr 0x88003557ec0c
[335207.782971] radeon :00:01.0: fence driver on ring 4 use gpu addr 
0x3c10 and cpu addr 0x88003557ec10
[335207.801597] [drm] ring test on 0 

Bug#817930: manpages-posix-dev: Please ship symlinks for to man pages with multiple functions

[Ben Longbons]

Package: manpages-posix-dev
Version: 2013a-1
Severity: wishlist

Dear Maintainer,

Many pages contain information for more than one function, so they
should be available under either name.

As a single example, pthread_spin_destroy and pthread_spin_init share
the same page, but you can only access the page via pthread_spin_destroy.


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

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

Versions of packages manpages-posix-dev depends on:
ii  manpages-posix  2013a-1

Versions of packages manpages-posix-dev recommends:
ii  manpages-dev  4.04-2

Versions of packages manpages-posix-dev suggests:
ii  konqueror [man-browser]  4:15.08.3-1
ii  man-db [man-browser] 2.7.5-1

-- no debconf information

Bug#815038: edgar-data: Lots of missing sounds

[Ben Longbons]

Package: edgar-data
Version: 1.21-1
Severity: normal

Dear Maintainer,

When playing this game, there are a lot of errors of the form:

Failed to load sound sound/boss/boulder_boss/roll
Failed to load sound sound/common/rock_shatter

The exact filenames vary depending on which map you're on.

Many of these sounds are played before there is any visible effect,
so not having audible cues has a negative effect on gameplay.

I have not investigated whether something is wrong with Debian's
packaging or whether upstream simply hasn't found any open-source sounds
yet.


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

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

Versions of packages edgar-data depends on:
ii  ttf-dejavu-core  2.35-1

edgar-data recommends no packages.

edgar-data suggests no packages.

-- no debconf information

Bug#803523: After installing plasma-pa I have 2 volume applets too

[Ben Longbons]

Thanks for isolating, removing that package worked.

I guess this bug can be reassigned to tell plasma-pa to suicide itself
in the presence of its superior. Otherwise, the packages should add a
Conflicts: dependency or something.

On Wed, Nov 18, 2015 at 12:10 PM, Diederik de Haas
 wrote:
> I just installed plasma-pa and when I rebooted I have two applets too.
> Do you have that package too?

Bug#803612: libqt5gui5: "ambiguous shortcut" regression

[Ben Longbons]

A fresh user does not reproduce by default, but  with a little help
from strace I managed to find a way to reproduce what's happening with
my main user.

Edit the file ~/.config/kdeglobals, and add or replace the following lines:

[Shortcuts]
New=Ctrl+N; Ctrl+N

(This is visible in systemsettings5 as Standard Shortcuts, but the UI
will prevent *setting* a conflict there now)

Then all Qt (not just KDE! Does Qt have some plugin mechanism
perhaps?) applications will read this file and conflict whenever you
try to create a new file.

Obviously some previous version of Qt (or even KDE) was buggy in that
it was capable of generating the config file with these contents.

But the current version of Qt remains buggy in that it is willing to
*read* such a file without discarding the duplicate.

-Ben


On Mon, Nov 2, 2015 at 8:33 AM, Lisandro Damián Nicanor Pérez Meyer
<perezme...@gmail.com> wrote:
> On Sunday 01 November 2015 14:28:08 Ben Longbons wrote:
>> Among others, it happens in Kate (but it is not KDE-specific, it
>> happens in pure Qt applications too, I just can't think of one off the
>> top of my head that everyone is likely to have installed).
>>
>> Press Ctrl-N, receive a popup instead of a new file:
>>
>> (title) Ambiguous Shortcut Detected — Kate
>> The key sequence 'Ctrl+N' is ambiguous. Use 'Configure Shortcuts'
>> from the 'Settings' menu to solve the ambiguity.
>> No action will be triggered.
>
> Still can't reproduce it. Moreover my kate config is the default.
>
> Can you try creating a new user and see what happens?
>
>
> --
> "So long, and thanks for all the fish!"
>   The Hitchhickers guide to the Galaxy
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/

Bug#803612: libqt5gui5: "ambiguous shortcut" regression

[Ben Longbons]

Among others, it happens in Kate (but it is not KDE-specific, it
happens in pure Qt applications too, I just can't think of one off the
top of my head that everyone is likely to have installed).

Press Ctrl-N, receive a popup instead of a new file:

(title) Ambiguous Shortcut Detected — Kate
The key sequence 'Ctrl+N' is ambiguous. Use 'Configure Shortcuts'
from the 'Settings' menu to solve the ambiguity.
No action will be triggered.

Go to Settings -> Configure shortcuts, search for "new"
Set alternate shortcut to "custom - None".

Ctrl-N now works.

bad kate package: 4:15.08.2-1 (stretch/sid)
good kate package: 4:4.14.2-2 (jessie - can be easily downgraded)

On further investigation, the Qt4 version of kate had the alternate
shortcut set to None by default instead of a duplicate of the primary
shortcut like the Qt5 version does.

-Ben

On Sun, Nov 1, 2015 at 9:47 AM, Lisandro Damián Nicanor Pérez Meyer
<perezme...@gmail.com> wrote:
> tag 803612 moreinfo unreproducible
> thanks
>
> On Saturday 31 October 2015 12:58:49 Ben Longbons wrote:
>> Package: libqt5gui5
>> Version: 5.5.1+dfsg-5
>> Severity: important
>>
>> Dear Maintainer,
>>
>> In all Qt applications, pressing nearly any shortcut does not perform
>> the requested action. Instead, it just pops up a box saying "ambiguous
>> shortcut detected".
>
> Hi Ben! For what it's worth I don't see this bahvior on any Qt5 app. It would
> be good if you can give us more info, like what DM are you using, an example
> app and shortcut to use, etc.
>
>> This is caused by the fact that, by default, the primary and alternate
>> keybindings are set to the same key sequence.
>>
>> Apparently, the dispatcher
>> logic is unable to detect that the two shortcuts refer to the same
>> action.
>>
>> In previous versions of Qt, this was not a problem.
>
> Please please give us an example.
>
> Kinds regards, Lisandro.
>
> --
> Antiguo proverbio de El Machi: "Dado el apropiado grado de profundidad, la
> ineptitud es indistinguible del sabotaje"
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/

Bug#803612: libqt5gui5: "ambiguous shortcut" regression

[Ben Longbons]

Package: libqt5gui5
Version: 5.5.1+dfsg-5
Severity: important

Dear Maintainer,

In all Qt applications, pressing nearly any shortcut does not perform
the requested action. Instead, it just pops up a box saying "ambiguous
shortcut detected".

This is caused by the fact that, by default, the primary and alternate
keybindings are set to the same key sequence. Apparently, the dispatcher
logic is unable to detect that the two shortcuts refer to the same
action.

In previous versions of Qt, this was not a problem.

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

Kernel: Linux 4.2.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 libqt5gui5 depends on:
ii  fontconfig   2.11.0-6.3
ii  libc62.19-22
ii  libegl1-mesa [libegl1-x11]   10.6.8-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libgl1-mesa-glx [libgl1] 10.6.8-1
ii  libglib2.0-0 2.46.1-1
ii  libharfbuzz0b1.0.1-1+b1
ii  libinput10   1.0.1-1
ii  libjpeg62-turbo  1:1.4.1-2
ii  libmtdev11.1.5-1
ii  libpng12-0   1.2.50-2+b2
ii  libqt5core5a [qtbase-abi-5-5-1]  5.5.1+dfsg-5
ii  libqt5dbus5  5.5.1+dfsg-5
ii  libqt5network5   5.5.1+dfsg-5
ii  libqt5xcbqpa55.5.1+dfsg-5
ii  libstdc++6   5.2.1-22
ii  libudev1 227-2
ii  libx11-6 2:1.6.3-1
ii  libxkbcommon00.5.0-1
ii  libxrender1  1:0.9.8-1+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5  5.5.1-2

Versions of packages libqt5gui5 suggests:
pn  libqt5libqgtk2 
ii  qt5-image-formats-plugins  5.5.1-2
ii  qtwayland5 5.5.1-2

-- no debconf information

Bug#803523: kmix: Should kill competing volume applet

[Ben Longbons]

Package: kmix
Version: 4:15.08.1-1
Severity: normal

Dear Maintainer,

Since I upgraded to KDE5, there is another volume applet in the system tray.

I don't know where it is coming from, it just says "Plasma" when I try
xwininfo.

I don't want to use the other one, because kmix is so much better (for
example, per application volume controls, which I use a lot).

The other audio applet can be *hidden* in the system tray options (under
Extra Items), but still appears to be handling volume-key presses, often
leading to race conditions (e.g. one application thinks the press was
held long enough to change the volume 20%, then the other detects it and
tries to change it 5%, but actually sets it *back* 15%).

Please figure out where the inferior volume control applet is coming
from, and ensure that it dies whenever kmix is available.

Thanks.

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

Kernel: Linux 4.2.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 kmix depends on:
ii  kde-runtime  4:15.08.2-1
ii  libasound2   1.0.29-1
ii  libc62.19-22
ii  libcanberra0 0.30-2.1
ii  libkdecore5  4:4.14.13-1
ii  libkdeui54:4.14.13-1
ii  libplasma3   4:4.14.13-1
ii  libpulse-mainloop-glib0  7.0-1
ii  libpulse07.0-1
ii  libqt4-dbus  4:4.8.7+dfsg-3
ii  libqt4-xml   4:4.8.7+dfsg-3
ii  libqtcore4   4:4.8.7+dfsg-3
ii  libqtgui44:4.8.7+dfsg-3
ii  libsolid44:4.14.13-1
ii  libstdc++6   5.2.1-22

kmix recommends no packages.

kmix suggests no packages.

-- no debconf information

Bug#801819: pypy: Creates strange virtualenvs

[Ben Longbons]

Package: pypy
Version: 2.6.1+dfsg-2
Severity: normal

Dear Maintainer,

Why pypy is specified as the interpreter for a virtualenv, the layout
is significantly different than the layout for cpython virtualenvs.

I noticed this because with cpython, it is possible to install more than
one executable to the same virtualenv directory, and the files do not
interfere, but with pypy they do.

I believe this is Debian-specific, since upstreams uses cpython's
site-packages by design (at least, the pypy3 build does, I haven't
needed to install upstream pypy2).

In particular:

* pypy installs `include/` as a symlink instead of a directory containing
  symlinks (can be fixed with --always-copy, but ugh)

* pypy installs site-packages/ at the top level instead of in
  lib/python2.7/

$ cat > test-script.sh << EOF
#!/bin/sh
set -e
mkdir -p venv-tests
cd venv-tests
for python in python2.7 pypy
do
rm -rf venv-$python
virtualenv -p $python venv-$python
echo == Files for $python ==
find venv-$python | grep -v dist-info/ | sed 's:[^/]*\.py[coi]\?$:*.py:' | 
sort -u
echo
done
EOF
$ sh test-script.sh
New python executable in venv-python2.7/bin/python2.7
Also creating executable in venv-python2.7/bin/python
Installing setuptools, pip...done.
Running virtualenv with interpreter /usr/bin/python2.7
== Files for python2.7 ==
venv-python2.7
venv-python2.7/bin
venv-python2.7/bin/activate
venv-python2.7/bin/activate.csh
venv-python2.7/bin/activate.fish
venv-python2.7/bin/easy_install
venv-python2.7/bin/easy_install-2.7
venv-python2.7/bin/pip
venv-python2.7/bin/pip2
venv-python2.7/bin/pip2.7
venv-python2.7/bin/*.py
venv-python2.7/bin/python
venv-python2.7/bin/python2
venv-python2.7/bin/python2.7
venv-python2.7/include
venv-python2.7/include/python2.7
venv-python2.7/lib
venv-python2.7/lib/python2.7
venv-python2.7/lib/python2.7/distutils
venv-python2.7/lib/python2.7/distutils/distutils.cfg
venv-python2.7/lib/python2.7/distutils/*.py
venv-python2.7/lib/python2.7/encodings
venv-python2.7/lib/python2.7/lib-dynload
venv-python2.7/lib/python2.7/no-global-site-packages.txt
venv-python2.7/lib/python2.7/orig-prefix.txt
venv-python2.7/lib/python2.7/*.py
venv-python2.7/lib/python2.7/site-packages
venv-python2.7/lib/python2.7/site-packages/_markerlib
venv-python2.7/lib/python2.7/site-packages/_markerlib/*.py
venv-python2.7/lib/python2.7/site-packages/pip
venv-python2.7/lib/python2.7/site-packages/pip-1.5.6.dist-info
venv-python2.7/lib/python2.7/site-packages/pip/backwardcompat
venv-python2.7/lib/python2.7/site-packages/pip/backwardcompat/*.py
venv-python2.7/lib/python2.7/site-packages/pip/commands
venv-python2.7/lib/python2.7/site-packages/pip/commands/*.py
venv-python2.7/lib/python2.7/site-packages/pip/*.py
venv-python2.7/lib/python2.7/site-packages/pip/vcs
venv-python2.7/lib/python2.7/site-packages/pip/vcs/*.py
venv-python2.7/lib/python2.7/site-packages/pkg_resources
venv-python2.7/lib/python2.7/site-packages/pkg_resources/*.py
venv-python2.7/lib/python2.7/site-packages/pkg_resources/_vendor
venv-python2.7/lib/python2.7/site-packages/pkg_resources/_vendor/packaging
venv-python2.7/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/*.py
venv-python2.7/lib/python2.7/site-packages/pkg_resources/_vendor/*.py
venv-python2.7/lib/python2.7/site-packages/*.py
venv-python2.7/lib/python2.7/site-packages/setuptools
venv-python2.7/lib/python2.7/site-packages/setuptools-18.3.1.dist-info
venv-python2.7/lib/python2.7/site-packages/setuptools/command
venv-python2.7/lib/python2.7/site-packages/setuptools/command/*.py
venv-python2.7/lib/python2.7/site-packages/setuptools/*.py
venv-python2.7/lib/python2.7/site-packages/setuptools/script (dev).tmpl
venv-python2.7/lib/python2.7/site-packages/setuptools/script.tmpl
venv-python2.7/lib/python-wheels
venv-python2.7/lib/python-wheels/chardet-2.3.0-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/colorama-0.3.3-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/distlib-0.2.1-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/html5lib-0.999-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/pip-1.5.6-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/requests-2.7.0-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/setuptools-18.3.1-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/six-1.10.0-py2.py3-none-any.whl
venv-python2.7/lib/python-wheels/urllib3-1.11-py2.py3-none-any.whl
venv-python2.7/local
venv-python2.7/local/bin
venv-python2.7/local/include
venv-python2.7/local/lib

New pypy executable in venv-pypy/bin/pypy
Installing setuptools, pip...done.
Running virtualenv with interpreter /usr/bin/pypy
== Files for pypy ==
venv-pypy
venv-pypy/bin
venv-pypy/bin/activate
venv-pypy/bin/activate.csh
venv-pypy/bin/activate.fish
venv-pypy/bin/easy_install
venv-pypy/bin/easy_install-2.7
venv-pypy/bin/pip
venv-pypy/bin/pip2
venv-pypy/bin/pip2.7
venv-pypy/bin/*.py
venv-pypy/bin/pypy
venv-pypy/bin/python
venv-pypy/bin/python2
venv-pypy/bin/python2.7
venv-pypy/include
venv-pypy/lib

Bug#800747: wesnoth-1.12: Some buttons don't respond to mouse clicks

[Ben Longbons]

Control: clone -1 kwin-x11
Control: retitle -1 Wesnoth UI does not work properly if WM does not
respect requested size.
Control: retitle -2 KWin 5 does not respect resize requests if the
application starts maximized.

(hopefully that control stuff works right ...)

I have further isolated the bug, and not filed it upstream.

What happens is that wesnoth starts in a window that is maximized (I'm
running under kwin 5 at 1366x768), and then I use the kwin
"fullscreen" option (either from the window corner menu or the
keyboard shortcut - alt-enter by default) to change it to fullscreen.
Any buttons that were not visible in the maximized window (off the
bottom of the screen - I have both a top taskbar and a bottom one) are
not clickable.

I also observed that, when the window is maximized, going into
preferences and requesting a resolution change does NOT work. This is
likely related - wesnoth should only be drawing its UI in the
resolution that the window manager gives it, regardless of whether or
not that resolution is satisfying its request. I believe that other
WMs typically implement "resize to native resolution" as an implicit
request for fullscreen.

Note: the reason I start Wesnoth in windowed mode and then switch it
to fullscreen from the WM is that SDL1's fullscreen support steals all
input focus from the WM and forcibly changes the resolution, whereas
WM fullscreen is implemented as resize with no border. I *think* SDL2
supports the "nice" fullscreen (not sure by default?).

Upstream documentation indicates that 1.13 should be switching to SDL2
eventually, but that doesn't seem to have been done yet for the
version that Debian has packaged.

Workaround: leave fullscreen, unmaximize the wesnoth window, then
resize it (either from in-game or by dragging the corners in the WM -
which will give a resize event that wesnoth recognizes), then enter
fullscreen again. Note that merely unmaximizing (without resizing)
will leave wesnoth in a buggy state, and is a simple way to make even
*more* buttons unresponsive.

Summary: I believe there are at least two bugs here: the KWin not
respecting the application's request, and Wesnoth (or possibly SDL)
not properly respecting it. I am fairly certain that the
mouse-specific issue is merely a side effect of the resize-related
bugs.

-Ben


On Thu, Oct 8, 2015 at 2:05 PM, Vincent Cheng <vch...@debian.org> wrote:
> Control: tags -1 + moreinfo unreproducible
>
> Hi Ben,
>
> On Sat, Oct 3, 2015 at 12:45 AM, Ben Longbons <brlongb...@gmail.com> wrote:
>> Package: wesnoth-1.12
>> Version: 1:1.12.4-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> A handful of the UI buttons cannot be clicked (tested with multiple mice).
>>
>> In particular I have noted:
>>
>> * The "End Turn / End Scenario" button (action menu or ctrl-space works)
>> * The "OK" button in the Addons Manager (double-click or enter works)
>> * The "Close" button in Help/Unit Description (escape works)
>>
>> This did not occur with wesnoth-1.10.
>>
>> Using the keyboard shortcuts or alternative mouse actions above still works,
>> and the mouse works perfectly on all other buttons that I have noticed.
>>
>> (I normally use the keyboard, but was demoing the game for a friend, so
>> this was quite embarrassing.)
>>
>> There is also something funny with clicking on a unit that has
>> had the spacebar pressed to ignore its remaining move for the N key. It
>> cannot be moved unless you press space again and *then* press the N key.
>
> Unfortunately I cannot reproduce this at all; UI buttons work as
> expected for me.
>
> I have no idea what might be causing this issue; you may want to
> report this directly upstream and see if they have any suggestions.
> Instructions for filing a bug report for wesnoth can be found at [1].
>
> Regards,
> Vincent
>
> [1] http://wiki.wesnoth.org/Reportingbugs

Bug#800747: wesnoth-1.12: Some buttons don't respond to mouse clicks

[Ben Longbons]

Package: wesnoth-1.12
Version: 1:1.12.4-1
Severity: important

Dear Maintainer,

A handful of the UI buttons cannot be clicked (tested with multiple mice).

In particular I have noted:

* The "End Turn / End Scenario" button (action menu or ctrl-space works)
* The "OK" button in the Addons Manager (double-click or enter works)
* The "Close" button in Help/Unit Description (escape works)

This did not occur with wesnoth-1.10.

Using the keyboard shortcuts or alternative mouse actions above still works,
and the mouse works perfectly on all other buttons that I have noticed.

(I normally use the keyboard, but was demoing the game for a friend, so
this was quite embarrassing.)

There is also something funny with clicking on a unit that has
had the spacebar pressed to ignore its remaining move for the N key. It
cannot be moved unless you press space again and *then* press the N key.

-Ben

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

Kernel: Linux 4.1.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 wesnoth-1.12 depends on:
ii  wesnoth-1.12-aoi1:1.12.4-1
ii  wesnoth-1.12-core   1:1.12.4-1+b1
ii  wesnoth-1.12-data   1:1.12.4-1
ii  wesnoth-1.12-did1:1.12.4-1
ii  wesnoth-1.12-dm 1:1.12.4-1
ii  wesnoth-1.12-dw 1:1.12.4-1
ii  wesnoth-1.12-ei 1:1.12.4-1
ii  wesnoth-1.12-httt   1:1.12.4-1
ii  wesnoth-1.12-l  1:1.12.4-1
ii  wesnoth-1.12-low1:1.12.4-1
ii  wesnoth-1.12-nr 1:1.12.4-1
ii  wesnoth-1.12-sof1:1.12.4-1
ii  wesnoth-1.12-sotbe  1:1.12.4-1
ii  wesnoth-1.12-thot   1:1.12.4-1
ii  wesnoth-1.12-trow   1:1.12.4-1
ii  wesnoth-1.12-tsg1:1.12.4-1
ii  wesnoth-1.12-ttb1:1.12.4-1
ii  wesnoth-1.12-utbs   1:1.12.4-1

Versions of packages wesnoth-1.12 recommends:
ii  wesnoth-1.12-music  1:1.12.4-1

wesnoth-1.12 suggests no packages.

-- no debconf information

Bug#799348: musl-dev: Should be in Section: libdevel

[Ben Longbons]

Package: musl-dev
Version: 1.1.9-1
Severity: minor

Dear Maintainer,

I don't like having manually-installed packages in Section: libs. Please
correct the section.

This also applies to musl-tools.


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

Kernel: Linux 4.1.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 musl-dev depends on:
ii  musl  1.1.9-1

Versions of packages musl-dev recommends:
pn  linux-musl-dev  

musl-dev suggests no packages.

-- no debconf information

Bug#798421: Please don't depend specifically on the OpenSSL variant of Curl

[Ben Longbons]

For technical measures, the only place in libgit2-dev where curl
matters is in the Libs.private section of the .pc file, which is only
used for static linking. The choice of curl does not form part of the
dynamic library's ABI, other than the fact that if a dependent program
tries to link the other curl as well, it will pull in both and you'll
have DLL hell.

None of this solve the legal problems with OpenSSL, but they're kinda
probably planning relicensing soon ...

Bug#799350: libgccjit-5-dev:amd64: should be in Section: libdevel

[Ben Longbons]

Package: libgccjit-5-dev
Version: 5.2.1-17
Severity: minor

Dear Maintainer,

As a rule, I should have no manually installed packages from Section:
libs. Please fix the section of this dev package.


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

Kernel: Linux 4.1.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 libgccjit-5-dev:amd64 depends on:
ii  gcc-5-base 5.2.1-17
ii  libgccjit0 5.2.1-17
ii  multiarch-support  2.19-19

libgccjit-5-dev:amd64 recommends no packages.

Versions of packages libgccjit-5-dev:amd64 suggests:
ii  libgccjit-5-dbg  5.2.1-17

-- no debconf information

Bug#799430: libkf5texteditor5: libgit2 upgrade pulls in OpenSSL, conflicting with the GPL

[Ben Longbons]

Package: libkf5texteditor5
Version: 5.13.0-1+b1
Severity: serious
Justification: license violation

Dear Maintainer,

libgit2-23 now links to OpenSSL, which conflicts with the GPL license
used by this package.

See #798421 for more information.


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

Kernel: Linux 4.1.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 libkf5texteditor5 depends on:
ii  ktexteditor-data   5.13.0-1
ii  libc6  2.19-20
ii  libgit2-23 0.23.1-1
ii  libjs-underscore   1.7.0~dfsg-1
ii  libkf5archive5 5.13.0-1
ii  libkf5codecs5  5.13.0-1
ii  libkf5completion5  5.13.0-1
ii  libkf5configcore5  5.13.0-1
ii  libkf5configgui5   5.13.0-1
ii  libkf5configwidgets5   5.13.0-2
ii  libkf5coreaddons5  5.13.0-1
ii  libkf5guiaddons5   5.13.0-1
ii  libkf5i18n55.13.0-1
ii  libkf5iconthemes5  5.13.0-1
ii  libkf5itemviews5   5.13.0-1
ii  libkf5jobwidgets5  5.13.0-1
ii  libkf5kiocore5 5.13.0-1
ii  libkf5kiofilewidgets5  5.13.0-1
ii  libkf5kiowidgets5  5.13.0-1
ii  libkf5parts5   5.13.0-1
ii  libkf5sonnetcore5  5.13.0-1
ii  libkf5sonnetui55.13.0-1
ii  libkf5textwidgets5 5.13.0-1
ii  libkf5widgetsaddons5   5.13.0-1
ii  libkf5xmlgui5  5.13.0-1
ii  libqt5core5a   5.4.2+dfsg-9
ii  libqt5gui5 5.4.2+dfsg-9
ii  libqt5printsupport55.4.2+dfsg-9
ii  libqt5script5  5.4.2+dfsg-4
ii  libqt5widgets5 5.4.2+dfsg-9
ii  libqt5xml5 5.4.2+dfsg-9
ii  libstdc++6 5.2.1-17

Versions of packages libkf5texteditor5 recommends:
ii  ktexteditor-katepart  5.13.0-1+b1

libkf5texteditor5 suggests no packages.

-- no debconf information

Bug#799431: kate: libgit2 upgrade pulls in OpenSSL, conflicting with the GPL

[Ben Longbons]

Package: kate
Version: 4:15.08.0-1
Severity: serious
Justification: license violation

Dear Maintainer,

libgit2-23 now links to OpenSSL, which conflicts with the GPL license
used by this package.

See #798421 for more information.


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

Kernel: Linux 4.1.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 kate depends on:
ii  kate5-data   4:15.08.0-1
ii  katepart 4:4.14.3-2
ii  ktexteditor-katepart 5.13.0-1+b1
ii  libc62.19-20
ii  libgit2-23   0.23.1-1
ii  libkf5activities55.13.0-1
ii  libkf5bookmarks5 5.13.0-1
ii  libkf5completion55.13.0-1
ii  libkf5configcore55.13.0-1
ii  libkf5configgui5 5.13.0-1
ii  libkf5configwidgets5 5.13.0-2
ii  libkf5coreaddons55.13.0-1
ii  libkf5dbusaddons55.13.0-1
ii  libkf5guiaddons5 5.13.0-1
ii  libkf5i18n5  5.13.0-1
ii  libkf5iconthemes55.13.0-1
ii  libkf5itemmodels55.13.0-1
ii  libkf5jobwidgets55.13.0-1
ii  libkf5kiocore5   5.13.0-1
ii  libkf5kiofilewidgets55.13.0-1
ii  libkf5kiowidgets55.13.0-1
ii  libkf5newstuff5  5.13.0-1
ii  libkf5notifications5 5.13.0-1
ii  libkf5parts5 5.13.0-1
ii  libkf5plasma55.13.0-1
ii  libkf5service5   5.13.0-2
ii  libkf5texteditor55.13.0-1+b1
ii  libkf5textwidgets5   5.13.0-1
ii  libkf5threadweaver5  5.13.0-1
ii  libkf5wallet55.13.0-1
ii  libkf5widgetsaddons5 5.13.0-1
ii  libkf5windowsystem5  5.13.0-3
ii  libkf5xmlgui55.13.0-1
ii  libqt5core5a 5.4.2+dfsg-9
ii  libqt5dbus5  5.4.2+dfsg-9
ii  libqt5gui5   5.4.2+dfsg-9
ii  libqt5sql5   5.4.2+dfsg-9
ii  libqt5widgets5   5.4.2+dfsg-9
ii  libqt5xml5   5.4.2+dfsg-9
ii  libstdc++6   5.2.1-17
ii  plasma-framework 5.13.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.13.0-1
ii  qml-module-qtquick-layouts   5.4.2-2+b1
ii  qml-module-qtquick2  5.4.2-6

kate recommends no packages.

Versions of packages kate suggests:
ii  aspell 0.60.7~20110707-3
ii  ispell 3.4.00-3
ii  khelpcenter4:5.4.1-1
ii  konsole-kpart  4:15.08.0-1

-- no debconf information

Bug#798421: Please don't depend specifically on the OpenSSL variant of Curl

[Ben Longbons]

Control: severity -1 serious


Actually, you can't afford for this to be wishlist, it's already led
to a license violation of two rdepends.

Looking at the rdepends:

Not okay, GPL:
  kate, #799431
  libkf5texteditor5, #799430

Looks okay:
  libgit2-dbg
  libgit2-dev
  libgit2-glib-1.0-0
  python-pygit2
  python3-pygit2
  ruby-rugged

Bug#799325: weston: won't start despite having an active logind session

[Ben Longbons]

Package: weston
Version: 1.8.0-3
Severity: important

Dear Maintainer,

According to README.Debian, having an active logind session should be
sufficient to start weston without being in the weston-launch group.

This does not work.

$ loginctl list-sessions
   SESSIONUID USER SEAT
   198   1000 ben  seat0   
 8   1000 ben  seat0   
   262   1000 ben  seat0   
   197128 sddm seat0   

4 sessions listed.

$ loginctl show-session 262
Id=262
Name=ben
Timestamp=Thu 2015-09-17 14:33:40 PDT
TimestampMonotonic=111440115978
VTNr=2
TTY=/dev/tty2
Remote=no
Service=login
Scope=session-262.scope
Leader=25537
Audit=262
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=1442525896738975
IdleSinceHintMonotonic=111715924138

$ weston-launch
weston-launch: Permission denied. You should either:
 - enable systemd session support for weston-launch.
 - or add yourself to the 'weston-launch' group.

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

Kernel: Linux 4.1.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 weston depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.19-19
ii  libcairo2   1.14.2-2
ii  libcolord2  1.2.11-1
ii  libdrm2 2.4.64-1
ii  libegl1-mesa [libegl1-x11]  10.6.3-1
ii  libgbm1 10.6.3-1
ii  libgles2-mesa [libgles2]10.6.3-1
ii  libglib2.0-02.44.1-1.1
ii  libinput10  1.0.1-1
ii  libjpeg62-turbo 1:1.4.1-2
ii  liblcms2-2  2.6-3+b3
ii  libmtdev1   1.1.5-1
ii  libpam0g1.1.8-3.1
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpixman-1-0   0.32.6-3
ii  libpng12-0  1.2.50-2+b2
ii  libudev1225-1
ii  libwayland-client0  1.8.1-1
ii  libwayland-cursor0  1.8.1-1
ii  libwayland-egl1-mesa [libwayland-egl1]  10.6.3-1
ii  libwayland-server0  1.8.1-1
ii  libx11-62:1.6.3-1
ii  libx11-xcb1 2:1.6.3-1
ii  libxcb-composite0   1.10-3+b1
ii  libxcb-render0  1.10-3+b1
ii  libxcb-shape0   1.10-3+b1
ii  libxcb-shm0 1.10-3+b1
ii  libxcb-xfixes0  1.10-3+b1
ii  libxcb-xkb1 1.10-3+b1
ii  libxcb1 1.10-3+b1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxkbcommon0   0.5.0-1

Versions of packages weston recommends:
ii  libgl1-mesa-dri  10.6.3-1

weston suggests no packages.

-- no debconf information

Bug#799115: qemu-user-static: Unsupported syscalls (sys_name_to_handle_at, sys_signalfd4) prevent booting systemd.

[Ben Longbons]

Package: qemu-user-static
Version: 1:2.4+dfsg-2
Severity: wishlist

Dear Maintainer,

I recently discovered systemd-nspawn and machinectl. After working
through various bugs (try to use at least systemd 226 on the host)
I started playing with emulated builds, but a full boot didn't work.

Note that calling systemd-nspawn *without* -b does produce a working
shell.

# cd /var/lib/machines
# arch=arm64
# qemu-debootstrap --arch=$arch jessie jessie_$arch
< snip lots of output>
# systemd-nspawn -bD jessie_$arch
Spawning container jessie_arm64 on /var/lib/machines/jessie_arm64.
Press ^] three times within 1s to kill container.
Failed to create directory /var/lib/machines/jessie_arm64/sys/fs/selinux: 
Read-only file system
Failed to create directory /var/lib/machines/jessie_arm64/sys/fs/selinux: 
Read-only file system
/etc/localtime is not a symlink, not updating container timezone.
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT 
+LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
Detected virtualization 'systemd-nspawn'.
Detected architecture 'arm64'.

Welcome to Debian GNU/Linux 8 (jessie)!

Set hostname to .
qemu: Unsupported syscall: 74
Failed to allocate manager object: Function not implemented
^]^]
Container jessie_arm64 terminated by signal KILL.

Looking at the arm64 syscall list, 264 is sys_name_to_handle_at and 74 is 
sys_signalfd4.

The same bug occurs with arm64, armel, armhf, mips, mipsel, ppc64el, s390s
(though the syscall numbers vary of course).

I did not test amd64 or i386 because my host is amd64 and I'm not aware
of any way to force qemu emulation on the native architecture.

It is possible that there are additional unimplemented syscalls that do
not get called until after the above succeed.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, arm64, armhf

Kernel: Linux 4.1.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)

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.5-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.12-1

-- no debconf information

Bug#792882: machinectl fails to login to container

[Ben Longbons]

I ran into this, and everything works now after upgrading all systemd
packages to 226-2 and rebooting.

Note that this bug is *completely* unrelated to having dbus installed
in the container or having /dev/pts/0 in /etc/securetty, it happens
before that is relevant.

Note that systemd-container does not have a versioned `Depends:` on
systemd, and `systemd` does not have a versioned `Suggests:` on
systemd-container (if that even makes sense). I have not tested what
happens when they are not upgraded in lockstep.

With 225-1:

* systemd-nspawn -b provides a login prompt (on /dev/console).
* If container is started with systemd-nspawn -b, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with machinectl start, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with systemctl start, machinectl login fails
(tries to use hosts's /dev/pts/0 instead of container's).

With 226-2:

* systemd-nspawn -b provides a login prompt (on /dev/console).
* If container is started with systemd-nspawn -b, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with machinectl start, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with systemctl start, machinectl login fails
(tries to use hosts's /dev/pts/0 instead of container's).

Note that `machinectl shell` has the same results as `machinectl
login` in the cases I have tested, which is not all of them.

Note that the error message differed depending on whether /dev/pts/0
existed on the host or not. If you are running KDE, it usually appears
graphically (to catch wall(1) notifications).

Bug#798405: gdb: Allow coinstallation of gdb and gdb-python2

[Ben Longbons]

Package: gdb
Version: 7.10-1
Severity: wishlist

Control: block -1 by 798401

(do read and fix the blocking bug first)

Dear Maintainer,

Since it is considered RC buggy to have gdb scripts that don't work
with both versions of GDB, it would be hugely useful if they could be
installed at the same time.

You can use the `update-alternatives` mechanism to select which gdb gets
the main name.

The contents of the packages are very similar, I do not anticipate any
fundamental problems, just packaging ones. I would guess you want to
split out a `gdb-data` package used by both. (Bikeshed: `gdb-common`?)

If you reject the creation of a new `gdb-data` package, you should change
`gdb-multiarch` and `gdb-mingw-w64` to depend on `gdb | gdb-python2`.

I have commented the below diff, and also ped some similar lines,
though note that it is somewhat wrong because of the blocking bug.

BEGIN DIFF

# extract both .deb files ...
$ diff -sr gdb-python2 gdb-python3

# Bug in gdb-python2, should be common
Only in gdb-python3: etc
# Bug in gdb-python2, should be common
Only in gdb-python3/usr/bin: gcore
Only in gdb-python3/usr/bin: gdb-add-index
# Bug in gdb-python2, should be common or named gdb-python2tui
Only in gdb-python3/usr/bin: gdbtui
# Grave bug, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798401
Files gdb-python2/usr/bin/gdb and gdb-python3/usr/bin/gdb are identical
# Bug in gdb-python2 - it should not ship this directory at all
Only in gdb-python3/usr/share/doc/gdb: 
# Bug in gdb-python2, should be in /usr/share/doc/gdb-python2/ or not at all
Files gdb-python2/usr/share/doc/gdb/check.log.gz and 
gdb-python3/usr/share/doc/gdb/check.log.gz are identical
# Okay
Only in gdb-python2/usr/share/doc: gdb-python2
# Okay, should be common
Files under gdb-python2/usr/share/gdb/ and 
gdb-python3/usr/share/gdb/ are identical
# Okay, should be common
# Note that gdb.1.gz is shipped in gdb-doc which is non-free due to stupid 
reasons.
Files gdb-python2/usr/share/man/man1/gcore.1.gz and 
gdb-python3/usr/share/man/man1/gcore.1.gz are identical
# Okay
Only in gdb-python3/usr/share/menu: gdb
Only in gdb-python2/usr/share/menu: gdb-python2

END DIFF

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, arm64, armhf

Kernel: Linux 4.1.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 gdb depends on:
ii  libbabeltrace-ctf1  1.2.4-1
ii  libbabeltrace1  1.2.4-1
ii  libc6   2.19-19
ii  libexpat1   2.1.0-7
ii  liblzma55.1.1alpha+20120614-2.1
ii  libncurses5 6.0+20150810-1
ii  libpython3.43.4.3-7
ii  libreadline66.3-8+b3
ii  libtinfo5   6.0+20150810-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gdb recommends:
ii  gdbserver 7.10-1
ii  libc6-dbg [libc-dbg]  2.19-19

Versions of packages gdb suggests:
ii  gdb-doc  7.6.2-1

-- no debconf information