Bug#976024: g++-10 crashes for bitpacked enum class

[Ben Wiederhake]

Also happens with gcc-snapshot, so this is definitely an upstream bug.
g++ (Debian 20201127-1) 11.0.0 20201127 (experimental) [master revision
3493b0c3281:5c47353bc97:5e9f814d754be790aec5b69a95699a8af2654058]

Reported upstream as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98043
Looks like a very similar (but not identical) bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97634

Cheers,
Ben

Bug#976024: g++-10 crashes for bitpacked enum class

[Ben Wiederhake]

Package: g++-10
Version: 10.2.0-16
Severity: normal
Tags: upstream

Dear Maintainer,

* What led up to the situation?

Compiling the following code crashes g++-10:

// g++-10 -std=c++2a -o /tmp/example.cpp.o -c example.cpp
enum class MyEnumClass { A };
struct MyClass {
MyEnumClass foobar : 8 { MyEnumClass::A };
};
bool some_function(MyClass x)
{
switch (x.foobar) {
case MyEnumClass::A:
return false;
}
}

See at the bottom the exact invocation, error messages, and g++ version.

This bug is a regression: g++-9 does *not* crash when compiling the above code.

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

The enum-class, bit-packing, seemingly incomplete switch-case, non-constant
switch-argument, all seem to be necessary to trigger the bug.

* What was the outcome of this action?

Compiler crash (error message see below)

* What outcome did you expect instead?

Either a successful compilation, or a compilation error; but not a compiler
crash.


Full error message and versions:

$ /usr/bin/g++-10 -std=c++2a -o /tmp/example.cpp.o -c example.cpp
example.cpp: In function ‘bool some_function(MyClass)’:
example.cpp:6:6: error: type precision mismatch in switch statement
6 | bool some_function(MyClass x)
  |  ^
switch (_1) , case 0: >
example.cpp:6:6: internal compiler error: ‘verify_gimple’ failed
0x128422d verify_gimple_in_seq(gimple*)
../../src/gcc/tree-cfg.c:5144
0xf85436 gimplify_body(tree_node*, bool)
../../src/gcc/gimplify.c:14888
0xf856a3 gimplify_function_tree(tree_node*)
../../src/gcc/gimplify.c:14978
0xdbbe27 cgraph_node::analyze()
../../src/gcc/cgraphunit.c:670
0xdbee27 analyze_functions
../../src/gcc/cgraphunit.c:1227
0xdbf9f2 symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:2986
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ /usr/bin/g++-10 --version
g++-10 (Debian 10.2.0-16) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /usr/bin/g++-9 -std=c++2a -o /tmp/example.cpp.o -c example.cpp
example.cpp: In function ‘bool some_function(MyClass)’:
example.cpp:12:1: warning: control reaches end of non-void function [-Wreturn-
type]
   12 | }
  | ^

$ /usr/bin/g++-9 --version
g++-9 (Debian 9.3.0-18) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux home 5.8.0-1-amd64 #1 SMP Debian 5.8.7-1 (2020-09-05) x86_64 GNU/Linux



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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages g++-10 depends on:
ii  gcc-1010.2.0-16
ii  gcc-10-base   10.2.0-16
ii  libc6 2.31-4
ii  libgmp10  2:6.2.0+dfsg-6
ii  libisl22  0.22.1-1
ii  libmpc3   1.2.0-1
ii  libmpfr6  4.1.0-3
ii  libstdc++-10-dev  10.2.0-16
ii  libzstd1  1.4.5+dfsg-4
ii  zlib1g1:1.2.11.dfsg-2

g++-10 recommends no packages.

Versions of packages g++-10 suggests:
pn  g++-10-multilib  
pn  gcc-10-doc   

-- no debconf information

Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running

[Ben Wiederhake]

Package: popularity-contest
Version: 1.70
Followup-For: Bug #960617

Dear Maintainer,

I also ran into this issue.

For some reason, setting USETOR="no" in /etc/popularity-contest.conf does not
do the trick for me. (It still fails.)

My "temporary workaround" is now to uninstall tor. (Let's hope I don't need it
for a while.)

Cheers,
Ben



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

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

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.19.7

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-136
ii  exim4-daemon-light [mail-transport-agent]  4.94-6
ii  gnupg  2.2.20-1

Versions of packages popularity-contest suggests:
ii  anacron   2.3-29
pn  tor   
pn  torsocks  

-- debconf information:
  popularity-contest/submiturls:
* popularity-contest/participate: true

Bug#964363: syncthing: Please update to version 1.6.1

[Ben Wiederhake]

Package: syncthing
Version: 1.1.4~ds1-5
Followup-For: Bug #964363

Dear Maintainer,

version 1.6.0 (and thus 1.6.1) contains some bugfixes that are very
interesting, specifically the limits applied by MaxConcurrentWriters and the
limit of maximum concurrent scans. Without these limits, syncthing spawns waaay
too many threads and makes the system unresponsive.

Please consider updating Syncthing to its latest upstream version, or at least
1.6.1.

Cheers,
Ben



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

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

Versions of packages syncthing depends on:
ii  libc6  2.30-8

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#964096: mesa: SIGSEGV in iris_dri.so using mpv/ffplay/vlc, Intel HD Graphics 530

[Ben Wiederhake]

Package: libgl1-mesa-dri
Version: 20.1.2-1
Severity: normal

mesa: SIGSEGV in iris_dri.so using mpv/ffplay/vlc, Intel HD Graphics 530

Dear Maintainer,

This is different from #959400.

I have a particular file [1] ripped from youtube, and trying to open it with
*any* of mpv, ffplay, or vlc results in the same few first seconds on audio,
and then a crash (SIGSEGV).
This bugs seems to happen with *every* Video I have available, no matter
whether it's webm or flv or mkv or mp4. Note that firefox has no trouble.

gdb points to stream_state in iris_blorp.c:62, which effectively dereferences
res=0x0. See backtrace below.

This is a different backtrace than #959400.
Before you ask: Yes, I can trigger #959400 by running glxgears. Again, this
seems to be a different bug from that.

Here's the relevant part of iris_blorp.c, function stream_state:
   struct pipe_resource *res = NULL;
   // …
   u_upload_alloc(…, …, …, …, …, , …);
   struct iris_bo *bo = iris_resource_bo(res);

The function iris_resource_bo() basically just reads from the given pointer.

My best guess: The function stream_state forgets to check from errors during
u_upload_alloc(). No idea why that would fail, but it does.
The function u_upload_alloc (u_upload_mgr.c:238) has two paths to return
nullptr, so this should be checked by stream_state.

Cheers,
Ben

EXAMPLE FILE

https://www.youtube.com/watch?v=D8EeWgXRYFc
Again, this seems to happen with basically every file, but just in case:
$ sha256sum 'Max Cooper - Supine Official video by Tom
Geraedts-D8EeWgXRYFc.mkv'
dbb4257a69ade0f888f10ebe86b5512e291c62f5b5dce33c989bade02496897b

GDB BACKTRACE

#0  stream_state (batch=0x5580c0f0, uploader=, size=12,
alignment=alignment@entry=64, out_offset=out_offset@entry=0x7fffce9c,
out_bo=out_bo@entry=0x0)
at ../src/gallium/drivers/iris/iris_blorp.c:62
#1  0x7fffe7d70251 in blorp_alloc_dynamic_state
(blorp_batch=0x7fffd7b0, blorp_batch=0x7fffd7b0, offset=0x7fffce9c,
alignment=64, size=)
at ../src/gallium/drivers/iris/iris_blorp.c:138
#2  blorp_emit_blend_state (params=0x7fffd050, batch=0x7fffd7b0) at
../src/intel/blorp/blorp_genX_exec.h:1080
#3  blorp_emit_pipeline (params=0x7fffd050, batch=0x7fffd7b0) at
../src/intel/blorp/blorp_genX_exec.h:1271
#4  blorp_exec (params=0x7fffd050, batch=0x7fffd7b0) at
../src/intel/blorp/blorp_genX_exec.h:2015
#5  iris_blorp_exec (blorp_batch=0x7fffd7b0, params=0x7fffd050) at
../src/gallium/drivers/iris/iris_blorp.c:310
#6  0x7fffe7f3b5a4 in blorp_clear (batch=batch@entry=0x7fffd7b0,
surf=surf@entry=0x7fffd7e0, format=ISL_FORMAT_B8G8R8X8_UNORM, swizzle=...,
swizzle@entry=..., level=level@entry=0, start_layer=0, num_layers=1, x0=0,
y0=0, x1=1280, y1=560, clear_color=..., color_write_disable=0x7fffd7d0)
at ../src/intel/blorp/blorp_clear.c:548
#7  0x7fffe7d4bb4d in clear_color
(ice=ice@entry=0x5580bc70, p_res=, level=, box=box@entry=0x7fffd8d0,
render_condition_enabled=render_condition_enabled@entry=true, format=, swizzle=..., color=...) at ../src/gallium/drivers/iris/iris_clear.c:389
#8  0x7fffe7d4c8bb in iris_clear (ctx=0x5580bc70, buffers=4,
scissor_state=, p_color=0x557d8e24, depth=,
stencil=)
at ../src/gallium/drivers/iris/iris_clear.c:680
#9  0x7fffe72dc2bb in st_Clear (ctx=0x557c6b20, mask=2) at
../src/mesa/state_tracker/st_cb_clear.c:540
#10 0x75cf601a in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x75ce9911 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x75cef0bd in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x5556659c in  ()
#14 0x5556c9cf in  ()
#15 0xc7f0 in main ()
(gdb) bt full
#0  stream_state (batch=0x7fffc81b8fe0, uploader=, size=12,
alignment=alignment@entry=64, out_offset=out_offset@entry=0x7fffcf7fbc5c,
out_bo=out_bo@entry=0x0)
at ../src/gallium/drivers/iris/iris_blorp.c:62
res = 0x0
ptr = 0x0
bo = 
#1  0x7fffcdc40251 in blorp_alloc_dynamic_state
(blorp_batch=0x7fffcf7fc570, blorp_batch=0x7fffcf7fc570, offset=0x7fffcf7fbc5c,
alignment=64, size=)
at ../src/gallium/drivers/iris/iris_blorp.c:138
ice = 
batch = 
blend =
  {YDitherOffset = 0, XDitherOffset = 0, ColorDitherEnable = false,
AlphaTestFunction = COMPAREFUNCTION_ALWAYS, AlphaTestEnable = false,
AlphaToCoverageDitherEnable = false, AlphaToOneEnable = false,
IndependentAlphaBlendEnable = false, AlphaToCoverageEnable = false}
state = 
offset = 4294967295
size = 
pos = 
blend_state_offset = 0
urb_deref_block_size = GEN_URB_DEREF_BLOCK_SIZE_32
ice = 0x7fffc81b8b60
batch = 0x7fffc81b8fe0
scale = 
skip_bits = 



-- Package-specific info:
glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:

Bug#958828: telegram-purple: FTBFS on big endian architectures

[Ben Wiederhake]

Heyaloha,

tl;dr: wontfix (cantfix)

It's awesome to see some activity! :D

I'm effectively the maintainer of telegram-purple. Not because I
actually *develop* it forward, but because I seem to be the only person
who responds to and manages pull requests, and occasionally make a new
release or a small adjustment here and there.

You might want to read up on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809623#155 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835141 for some
history. In short: My reason for abandoning debianization is that
libtgl, the underlying library, is unmaintained, unmaintainable, already
has several unfixed known bugs, and was never meant for its current use.
I'm just waiting for the day it stops working forever. Hence the attempt
to replace libtgl by TDLib:
https://github.com/majn/telegram-purple/issues/480

You are correct, libtgl is not really portable to big endian. I tried
once, here are the ruins of the attempt:
https://github.com/BenWiederhake/tgl/tree/historic/endian-correct
(Note that quite a lot has happened since then, for example merging
'tl-parser' into 'tgl'.)
The main issue is that tgl is littered with "write(fd, ,
sizeof(somestruct))" all over the place, reading and writing and
computing with internal structs that will be reused later. The best
approaches I can see are a) rewriting, b) wrapping everything in
reads/writes that copy the data to a temporary buffer, fix all endian'd
values, and only then write it to the fd, or c) just using TDLib.
All of these option sound terrible.

telegram-purple 1.4.3 can't go into Debian. I have no idea how you
managed to sneak 1.4.1 into Debian, given how buggy it is.

Holy cow, over a hundred users! And that's not yet counting the >100
people who installed it manually!
https://qa.debian.org/popcon.php?package=telegram-purple

If you want, I'd be happy to collaborate on porting of telegram-purple
away from libtgl and to tdlib, as outlined in this issue:
https://github.com/majn/telegram-purple/issues/480
Interested in making telegram-purple 2.0.0 together? :)

Cheers,
Ben

PS: For reference: Someone made an attempt to rewrite telegram-purple,
but the code is not much more than two stubs side-by-side, and there is
no license so I can't actually use it:
https://github.com/ars3niy/tdlib-purple/issues/2

Bug#956003: xfce4-panel: Memory leak in panel plugin wrapper

[Ben Wiederhake]

ytes in 8 blocks
==5086==indirectly lost: 0 bytes in 0 blocks
==5086==  possibly lost: 4,696 bytes in 47 blocks
==5086==still reachable: 1,548,565 bytes in 16,442 blocks
==5086==   of which reachable via heuristic:
==5086== length64   : 4,384 bytes in 76 blocks
==5086== newarray   : 2,144 bytes in 54 blocks
==5086== suppressed: 0 bytes in 0 blocks
==5086== Reachable blocks (those to which a pointer was found) are not shown.
==5086== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5086==
==5086== ERROR SUMMARY: 39 errors from 39 contexts (suppressed: 0 from 0)

Please find my patch attached.

I already submitted this bug upstream:
https://bugzilla.xfce.org/show_bug.cgi?id=16640
However, I'm impatient and don't want to have to restart my system / panel
plugins all the time,
and would be grateful for a 4.14.3-2 :)

Cheers,
Ben Wiederhake



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4-panel depends on:
ii  exo-utils0.12.11-1
ii  libatk1.0-0  2.34.1-1
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libexo-2-0   0.12.11-1
ii  libgarcon-1-00.6.4-1
ii  libgarcon-gtk3-1-0   0.6.4-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.14-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libwnck-3-0  3.36.0-1
ii  libx11-6 2:1.6.9-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4panel-2.0-4  4.14.3-1
ii  libxfce4ui-2-0   4.14.1-1+b1
ii  libxfce4util74.14.0-1
ii  libxfconf-0-34.14.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information
From 963a5942673e3a547d6e08e1ef54693ad02e3877 Mon Sep 17 00:00:00 2001
From: Ben Wiederhake 
Date: Sun, 5 Apr 2020 23:25:45 +0200
Subject: [PATCH] Fix memory leak in panel plugin wrapper

---
 wrapper/wrapper-plug.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/wrapper/wrapper-plug.c b/wrapper/wrapper-plug.c
index db973bd4..90c8d6af 100644
--- a/wrapper/wrapper-plug.c
+++ b/wrapper/wrapper-plug.c
@@ -191,6 +191,7 @@ wrapper_plug_draw (GtkWidget *widget,
  GTK_STYLE_PROPERTY_BACKGROUND_COLOR,
  , NULL);
   gdk_cairo_set_source_rgba (cr, rgba);
+  gdk_rgba_free (rgba);
 }

   /* draw the background color */
--
2.25.1

Bug#943607: pkg-mozilla-archive-keyring: Key expires soon (2019-11-13)

[Ben Wiederhake]

Package: pkg-mozilla-archive-keyring
Version: 1.2
Severity: important

Dear Maintainer,

I was recently cleaning up my keystore, when I noticed that the mozilla archive
key is about to expire in three weeks: 2019-11-13.

You can see it like this:

$ apt-key list 06C4AE2A
pub   rsa4096 2010-11-20 [SC] [expires: 2019-11-13]
  85F0 6FBC 75E0 67C3 F305  C3C9 85A3 D265 06C4 AE2A
uid   [ unknown] Debian Mozilla team APT archive 

I think it's a bad thing if this key expires before the new key is distributed,
so I opened this bug.  Let me know if I misunderstood the key system.

Cheers,
Ben



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

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

-- no debconf information

Bug#940296: teamviewer: Respect "disable" setting and don't override administrator

[Ben Wiederhake]

Package: teamviewer
Version: 14.5.5819
Severity: normal

Dear Maintainer,

I have teamviewer disabled by default, and stopped, to save resources.  My
intention is to only enable teamviewer when I need to give support to my
friends.

Steps to reproduce:
1. Disable and stop teamviewer:
$ systemctl disable teamviewer && systemctl stop teamviewer
2. Update teamviewer.  (Reinstallation probably triggers the same bug.)

Expected behavior:
Teamviewer is disabled and stopped, and should stay that way.

Actual behavior:
Teamviewer actively goes against being disabled, enables itself, and starts the
daemon.

This is incredibly annoying as I have to manually disable and stop teamviewer
on every update.
Also, it undermines the typical authority structure:  "The admin is right."
If your daemon is disabled, it should *stay* disabled.

Please remove that "feature", thanks.

Cheers,
Ben Wiederhake



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

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

Versions of packages teamviewer depends on:
ii  libc62.29-1
ii  libdbus-1-3  1.12.16-1
ii  libqt5dbus5  5.11.3+dfsg1-4
ii  libqt5gui5   5.11.3+dfsg1-4
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5webkit55.212.0~alpha2-21
ii  libqt5widgets5   5.11.3+dfsg1-4
ii  libqt5x11extras5 5.11.3-2
ii  qml-module-qtquick-controls  5.11.3-2
ii  qml-module-qtquick-dialogs   5.11.3-2
ii  qml-module-qtquick-layouts   5.11.3-4
ii  qml-module-qtquick-window2   5.11.3-4
ii  qml-module-qtquick2  5.11.3-4

Versions of packages teamviewer recommends:
ii  fonts-liberation  1:1.07.4-10

teamviewer suggests no packages.

-- no debconf information

Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)

[Ben Wiederhake]

Package: faketime
Version: 0.9.7-3
Severity: normal

Dear Maintainer,

I've tried to use faketime to build something reproducibly, by using the git
commit time.
Git offers shortcuts for the formats "iso" (e.g. "2019-09-06 03:14:37 +0200")
and "iso-strict" (e.g. "2019-09-06T03:14:37+02:00").

Steps to reproduce, and actual behavior in bash:

$ LC_ALL=C faketime -f "2019-09-06 03:14:37 02:00" true  # "iso"
[$? = 0]
$ LC_ALL=C faketime -f "2019-09-06T03:14:37+02:00" true  # "iso-strict"
Failed to parse FAKETIME timestamp: Success
[$? = 1]

Expected behavior: Either the second invocation should "just work",
or produce a more meaningful error message.

I prefer the first behavior, and "Success"
sounds like the parsing actually worked, just got handled wrongly,
so maybe this can be done easily?

For my little thing I'll just use git's "iso" shortcut.

Cheers,
Ben Wiederhake



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

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

Versions of packages faketime depends on:
ii  libc62.28-10
ii  libfaketime  0.9.7-3

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

Bug#912379: /usr/bin/pip3: TypeError on "list --outdated": uses different Version implementations

[Ben Wiederhake]

Package: python3-pip
Version: 9.0.1-2.3
Severity: normal
File: /usr/bin/pip3

Dear Maintainer,

I'm having trouble running this command:

pip3 list --outdated

Expected behavior: A list of outdated, local packages
Actual behavior: TypeError

Full error message:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in
main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 157, in
run
packages = self.get_outdated(packages, options)
  File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 168, in
get_outdated
dist for dist in self.iter_packages_latest_infos(packages, options)
  File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 169, in

if dist.latest_version > dist.parsed_version
TypeError: '>' not supported between instances of 'Version' and 'Version'

This is not Debian #878082.

Arch had a similar problem, there it was a packaging error:

https://github.com/pypa/pip/issues/5429

Could it be that the Debian package has a similar issue?

Cheers,
Ben



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

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

Versions of packages python3-pip depends on:
ii  ca-certificates20170717
ii  python-pip-whl 9.0.1-2.3
ii  python33.6.6-1
ii  python3-distutils  3.6.6-1

Versions of packages python3-pip recommends:
ii  build-essential 12.5
ii  python3-dev 3.6.6-1
ii  python3-setuptools  40.2.0-1
ii  python3-wheel   0.30.0-0.2

python3-pip suggests no packages.

-- no debconf information

Bug#909443: apt-clone: Silently fails when dpkg-repack fails

[Ben Wiederhake]

Package: apt-clone
Version: 0.4.1
Severity: normal

Dear Maintainer,

* What led up to the situation?

I invoked `apt-clone --with-dpkg-repack my-repacked.apt-clone.tar.gz`.

I have teamviewer installed, so one of the many packages is teamviewer.
Apparently, I deleted /etc/apt/sources.list.d/teamviewer.list at some point in
time.
This may have confused dpkg-repack.

* What was the outcome of this action?

The teamviewer package did not get repacked, and was missing from the generated
tarball.
No exit code indicated that there was an error.  (So automation would run into
trouble).

There was only one warning from apt-clone, buried among many other similar
lines:

dpkg-deb: Fehler: Conffile »/etc/apt/sources.list.d/teamviewer.list« kommt
nicht im Paket vor
dpkg -repack: Error running: dpkg-deb --build dpkg-repack.teamviewer.tTztGb
.
dpkg -repack: Problems were encountered in processing.
dpkg -repack: The package may be broken.

If this had been an important package (i.e., the printer drivers that brought
me here),
and if I hadn't caught this, then I would have been in trouble.

* What outcome did you expect instead?

I expected one of the following:
- Ideal: Set a non-zero exit code, include the "maybe broken" package anyway.
- Acceptable: Set a non-zero exit code.
- Acceptable: Set a non-zero exit code, refuse to generate apt-clone tarball.

Cheers,
Ben



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

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

Versions of packages apt-clone depends on:
ii  lsb-release  9.20170808
ii  python3  3.6.5-3
ii  python3-apt  1.6.2

Versions of packages apt-clone recommends:
ii  dpkg-repack  1.44

apt-clone suggests no packages.

-- no debconf information

Bug#892079: rakarrack: Cannot compile due to -Werror=format-security

[Ben Wiederhake]

Package: rakarrack
Version: 0.6.1-4+b2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

tl;dr: Remove `-Werror`!

History: I'm trying to rebuild rakarrack (#892077), and write a lot about it
(#892078).

Steps to reproduce: Install dependencies, run your favorite package-building-
command.  This will eventually invoke:

cd src/
g++ -DHAVE_CONFIG_H -I. -I. -I.   -Wdate-time -D_FORTIFY_SOURCE=2
-Wall -msse2 -mfpmath=sse  -ffast-math -pipe  -fsigned-char
-I/usr/include/freetype2 -g -O2 -fdebug-prefix-
map=/home/eispin/workspace/rakarrack-rebuild/rakarrack=. -fstack-protector-
strong -Wformat -Werror=format-security -c -o rakarrack.o rakarrack.cxx

Expected behavior: execute successfully, just like all the other steps.

Actual behavior: Fails with the message:

rakarrack.cxx:22892:37: error: format not a string literal and no
format arguments [-Werror=format-security]
   ok=fl_choice(temp2,"No","Yes",NULL);
 ^
This bugreport and the following link to a blog post are good arguments to
disable `-Werror=` for this project.

http://blog.schmorp.de/2016-02-27-tidbits-for-the-love-of-god-dont-use-
werror.html

Manual workaround: I'll try to remove `-Werror=` from the Makefile, unless I
have to open more bugreports for this package.

Cheers,
Ben Wiederhake



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

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

Versions of packages rakarrack depends on:
ii  jackd 5
ii  libasound21.1.3-5
ii  libc6 2.26-6
ii  libfltk1.11.1.10-23
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8-20180218-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libsamplerate00.1.9-1
ii  libsndfile1   1.0.28-4
ii  libstdc++68-20180218-1
ii  libx11-6  2:1.6.4-3
ii  libxft2   2.3.2-1+b2
ii  libxpm4   1:3.5.12-1
ii  libxrender1   1:0.9.10-1
ii  zlib1g1:1.2.8.dfsg-5

rakarrack recommends no packages.

rakarrack suggests no packages.

-- no debconf information

Bug#892078: rakarrack: Forgotten build-dep: Needs dpatch

[Ben Wiederhake]

Package: rakarrack
Version: 0.6.1-4+b2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

tl;dr: Add 'dpatch' to Build-Depends or similar.

History: I wanted to rebuild rakarrack from source in order to debug a problem
(#892077).
I guess that once upon a time, having cdbs implied that dpatch is available,
too.  This is not true anymore.

Reproducible steps:
- New system, have build-essential, devscripts, and many others available.
- Download dependencies: `sudo apt-get build-dep rakarrack`
- Download sources: `apt-get source rakarrack` (in fact I cloned the git repo)
- Build binary: `fakeroot ./debian/rules binary`

Expected behavior: Creates binary
Actual behavior: Fails with `make: dpatch: Command not found`.

Cheers,
Ben Wiederhake



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

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

Versions of packages rakarrack depends on:
ii  jackd 5
ii  libasound21.1.3-5
ii  libc6 2.26-6
ii  libfltk1.11.1.10-23
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8-20180218-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libsamplerate00.1.9-1
ii  libsndfile1   1.0.28-4
ii  libstdc++68-20180218-1
ii  libx11-6  2:1.6.4-3
ii  libxft2   2.3.2-1+b2
ii  libxpm4   1:3.5.12-1
ii  libxrender1   1:0.9.10-1
ii  zlib1g1:1.2.8.dfsg-5

rakarrack recommends no packages.

rakarrack suggests no packages.

-- no debconf information

Bug#892077: rakarrack: Segfaults after jackd upgrade

[Ben Wiederhake]

Package: rakarrack
Version: 0.6.1-4+b2
Severity: important

Dear Maintainer,

tl;dr: rakarrack always and immediately segfaults.

History: Today I upgraded a lot of packages, including jack.
For some reason I restarted rakarrack, and now I cannot start it again.

Expected behavior: Open GUI and start work.
Actual behavior: Immediate Segfault on start.

My best guess is that some update to jack changed the ABI somewhere, and
rakarrack just needs to be re-built.  I have not tested this yet.

Backtrace: See below.

Cheers,
Ben Wiederhake


Backtrace:

(gdb) run
Starting program: /usr/bin/rakarrack
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

rakarrack 0.6.1 - Copyright (c) Josep Andreu - Ryan Billing - Douglas
McClendon - Arnout Engelen
Try 'rakarrack --help' for command-line options.
[New Thread 0x77fb2700 (LWP 26628)]
[New Thread 0x77f31700 (LWP 26629)]

Thread 1 "rakarrack" received signal SIGSEGV, Segmentation fault.
Looper::setpreset (this=this@entry=0x55aa1d50, npreset=-186351280) at
../../src/Looper.C:361
361 ../../src/Looper.C: Datei oder Verzeichnis nicht gefunden.
(gdb) thread apply all bt

Thread 3 (Thread 0x77f31700 (LWP 26629)):
#0  0x766a0d38 in __libc_read (fd=5, buf=0x77f30d40, nbytes=4)
at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x75d459be in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#2  0x75d48fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#3  0x75d44756 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x7669751a in start_thread (arg=0x77f31700) at
pthread_create.c:465
#5  0x74b8c3ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x77fb2700 (LWP 26628)):
#0  0x7669d7fd in futex_wait_cancelable (private=,
expected=0, futex_word=0x55866b78)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55866b20,
cond=0x55866b50) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x55866b50, mutex=0x55866b20) at
pthread_cond_wait.c:655
#3  0x75d4511c in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#4  0x75d3cd95 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#5  0x75d44756 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
#6  0x7669751a in start_thread (arg=0x77fb2700) at
pthread_create.c:465
#7  0x74b8c3ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x77fb3740 (LWP 26624)):
#0  Looper::setpreset (this=this@entry=0x55aa1d50, npreset=-186351280)
at ../../src/Looper.C:361
#1  0x555ebdfa in Looper::Looper (this=0x55aa1d50,
efxoutl_=0x55866ba0, efxoutr_=0x55867bb0, size=1)
at ../../src/Looper.C:63
#2  0x555bf71e in RKR::RKR (this=0x7fee3600) at
../../src/process.C:270
#3  0x555699db in main (argc=1, argv=0x7fffe078) at
../../src/main.C:96
(gdb)



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

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

Versions of packages rakarrack depends on:
ii  jackd 5
ii  libasound21.1.3-5
ii  libc6 2.26-6
ii  libfltk1.11.1.10-23
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8-20180218-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libsamplerate00.1.9-1
ii  libsndfile1   1.0.28-4
ii  libstdc++68-20180218-1
ii  libx11-6  2:1.6.4-3
ii  libxft2   2.3.2-1+b2
ii  libxpm4   1:3.5.12-1
ii  libxrender1   1:0.9.10-1
ii  zlib1g1:1.2.8.dfsg-5

rakarrack recommends no packages.

rakarrack suggests no packages.

-- no debconf information

Bug#871717: xfce4-sensors-plugin: Newer version available / Memory leak

[Ben Wiederhake]

Package: xfce4-sensors-plugin
Version: 1.2.6-1.1
Severity: normal

Dear Maintainer,

newer versions have been available for a while, containing bugfixes in which
I'm interested:

http://archive.xfce.org/src/panel-plugins/xfce4-sensors-plugin/1.2/

Maybe it resolves other bugs in the Debian Tracker, too, but it solves at the
very least a memory leak: https://bugzilla.xfce.org/show_bug.cgi?id=12914
I ran into the same issue on a machine with less memory, was surprised that my
home machine doesn't have the same issue, and only after seeing the version
number I recalled that "1.2.6-1.1" is my own version containing the bugfix,
thus the different behavior.

Could I ask you to package the newer version?
Or in case the whole xfce suite has to be updated atomically: Could you include
the patch I posted in the bugzilla.xfce.org bugreport? [1]

Thanks for your work!

Cheers,
Ben
[1] https://bugzilla.xfce.org/attachment.cgi?id=6875



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

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

Versions of packages xfce4-sensors-plugin depends on:
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgtk2.0-0  2.24.31-2
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libpangoft2-1.0-01.40.6-1
ii  libsensors4  1:3.4.0-4
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  xfce4-panel  4.12.1-2

Versions of packages xfce4-sensors-plugin recommends:
ii  hddtemp 0.3-beta15-52+b1
ii  lm-sensors  1:3.4.0-4

Versions of packages xfce4-sensors-plugin suggests:
pn  xsensors  

-- no debconf information

Bug#865013: network-manager-gnome: Consistent segfault when connecting to WPA2 network

[Ben Wiederhake]

Package: network-manager-gnome
Version: 1.8.2-1
Followup-For: Bug #865013

Control: tags -1 - unreproducible

Dear Maintainer,

I think I'm seeing the same bug, since it also crashes in libnma.

Relevant part of gdb:

#0  0xb76b121e in modules_initialized (object=0x0, res=0x8104d8e0,
user_data=0x81058178) at src/libnma/nma-cert-chooser-button.c:95
self = 0x81058178 [NMACertChooserButton]
error = 0x0
modules = 0x0
iter = {stamp = -2134551640, user_data = 0x80c553c8, user_data2 = 0x1,
user_data3 = 0x80f8af20}

And line 95 is:

93  if (!modules) {
94  /* The Front Fell Off. */
95  g_critical ("Error getting registered modules: %s",
error->message);
96  g_error_free (error);
97  }

It tries to access the 'message' field of 'error', which is null.
So there is a soft-error (no modules found), which is then handled badly at
some point ('error' ends up being null-but-accessed).

'error' probably should be written by
'gck_modules_initialize_registered_finish',
and I have no idea why it doesn't.

Steps to reproduce on my system:
- run 'nm-connection-editor'
- select some encrypted WLAN (in my case, a home WLAN) for which the computer
doesn't have the password yet
- click the 'edit' button

Expected behavior:  Not sure how, but it should open the configuration dialog
eventually.

Actual behavior:  Segfault in src/libnma/nma-cert-chooser-button.c:95

Not sure if the problem is with gck or with libnma's usage of it.

Cheers,
Ben

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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-x11 [dbus-session-bus]  1.10.20-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgtk-3-0   3.22.16-1
ii  libjansson4  2.10-1
ii  libmm-glib0  1.6.8-1
ii  libnm0   1.8.2-1
ii  libnma0  1.8.2-1
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libsecret-1-00.18.5-3.1
ii  libselinux1  2.6-3+b2
ii  network-manager  1.8.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]  0.105-6

Versions of packages network-manager-gnome recommends:
pn  gnome-keyring
ii  iso-codes3.75-1
pn  mobile-broadband-provider-info   
ii  notification-daemon  3.20.0-1+b1
ii  xfce4-notifyd [notification-daemon]  0.3.6-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#865341: pagein: Segfaults roughly every 1 in ten executions

[Ben Wiederhake]

Hello,

in version 0.00.04, which you commited to git three hours ago, the bug 
is still present, although much more seldom.


I enabled core dumping, and looked at it through gdb.
Please find attached at "bt full" for version 0.00.04-1 as gdb prints it 
for the version with debug symbols.  It appears that the error is 
("still"?) with accessing mmaps.


For comparison: core dumps with version 0.00.03 mostly have their stack 
corrupted, and the rest crashes somewhere deep in 'scanf' while trying 
to read things from the stack; so probably stack corruption, too.


Btw, can you enable debug symbols again?  One litte "-g" in the CFLAGS 
increases the binary size only slightly, and makes debugging easier.  I 
did that by hand when reproducing the bug.


Cheers,
Ben Wiederhake
PS: Today I learned how *not* to use reportbug.  I assumed --body-file 
would either accept it as the full message, or allow me to edit it once 
more.  Oh well.
user@machine:~/workspace/pagein$ gdb ./pagein core
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 <http://gnu.org/licenses/gpl.html>
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 "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./pagein...done.
[New LWP 28377]
Core was generated by `./pagein -p 1073'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  pagein_proc_mmap (pages_touched=, prot=0xbfeeaa73 
"r--p", 
path=0xbfeeaae0 "/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0.1004.0", 
len=, 
end=3077554176, begin=, page_size=4096, mappings=0x811c28e8) 
at pagein.c:263
263 x += *ptr;
(gdb) set pagination off
(gdb) bt full
#0  pagein_proc_mmap (pages_touched=, prot=0xbfeeaa73 
"r--p", path=0xbfeeaae0 "/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0.1004.0", 
len=, end=3077554176, begin=, page_size=4096, 
mappings=0x811c28e8) at pagein.c:263
ptr = 0xb76fb000 
x = 
fd = 5
statbuf = {st_dev = 65025, __pad1 = 0, st_ino = 7606200, st_mode = 
33188, st_nlink = 1, st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 
132, st_blksize = 4096, st_blocks = 2696, st_atim = {tv_sec = 1497960752, 
tv_nsec = 83782983}, st_mtim = {tv_sec = 1487856812, tv_nsec = 0}, st_ctim = 
{tv_sec = 1490879804, tv_nsec = 871008154}, __glibc_reserved4 = 0, 
__glibc_reserved5 = 0}
off = 3077550080
prot_flags = 
mapped = 0xb770d000
#1  pagein_proc (mappings=0x811c28e8, page_size=4096, pid=1073, 
procs=0xbfeecf38, kthreads=0xbfeecf3c, total_pages_touched=0xbfeecf60) at 
pagein.c:337
begin = 3077541888
end = 3077554176
len = 
off = 
off_end = 
byte = 0 '\000'
mapped = 0x0
path = 
"/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0.1004.0\000\000-le32d4.cache-4\000png.so",
 '\000' 
prot = "r--p"
path = "/proc/1073/maps", '\000' ...
buffer = "b76f9000-b76fc000 r--p 0014c000 fe:01 7606200
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0.1004.0\n\000\000\000e32d4.cache-4\n\000ng.so\n\000)\n",
 '\000' ...
fdmem = 3
rc = 0
fpmap = 0x811c2008
pages = 26343
pages_touched = 22240
has_maps = 
#2  0x80054e0e in main (argc=, argv=) at 
pagein.c:493
ret = 
memfree_begin = 152728
memfree_end = -5227627996823549632
swapfree_begin = 1039448
swapfree_end = 0
delta = 
total_pages_touched = 0
procs = 0
total_procs = 
kthreads = 0
scale = 
usage = {ru_utime = {tv_sec = -1074868352, tv_usec = -2147137980}, 
ru_stime = {tv_sec = 0, tv_usec = -1074868204}, {ru_maxrss = -1217433600, 
__ru_maxrss_word = -1217433600}, {ru_ixrss = 10, __ru_ixrss_word = 10}, 
{ru_idrss = -1, __ru_idrss_word = -1}, {ru_isrss = -1217433600, __ru_isrss_word 
= -1217433600}, {ru_minflt = -1219166696, __ru_minflt_word = -1219166696}, 
{ru_majflt = -1217324968, __ru_majflt_word = -1217324968}, {ru_nswap = 
-1217433600, __ru_nswap_word = -1217433600}, {ru_inblock = -1074868108, 
__ru_inblock_word = -1074868108}, {ru_oublock = -1217155840, __ru_oublock_word 
= -1217155840}, {ru_msgsnd = 524288, __ru_msgsnd_word = 524288}, {ru_msgrcv = 
-1, __ru_msgrcv_word = -1}, {ru_nsignals = -2147123200, __ru_nsignals_word = 
-2147123200}, {ru_nvcsw = 3, __ru_nvcsw_word = 3}, {ru_nivcsw = -2147131877, 
__ru_nivcsw_word = -2147131877}}
pid = 
mappings = 
(gdb)

Bug#865341: pagein: Segfaults roughly every 1 in ten executions

[Ben Wiederhake]

Package: pagein
Version: 0.00.03-1
Severity: important

Dear Maintainer,

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

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

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

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Ben Wiederhake <benwiederhake.git...@gmx.de>
To: Debian Bug Tracking System <sub...@bugs.debian.org>
Subject: pagein: Segfaults roughly every 1 in ten executions
Message-ID: <149796559606.22041.12836038062408551702.reportbug@bewied-eeepc>
X-Mailer: reportbug 7.1.7
Date: Tue, 20 Jun 2017 15:33:16 +0200

Package: pagein
Version: 0.00.03-1
Severity: normal

Dear Maintainer,

How to reproduce:

user@machine:/$ sudo -s
root@machine:/# pagein -a -v
root@machine:/# pagein -a -v
root@machine:/# pagein -a -v
root@machine:/# pagein -a -v
# You get the idea.

Expected results:
Runs without issues, as described in the man page

Actual results:
Sometimes, it crashed without apparent reason.

Potentially relevant:
- 'pagein -a' also crashes, and more reliably.
- Architecture is i686.
- 1 GiB of physical RAM, and "swap in use" is greater than "mem free" according 
to /usr/bin/free
  (I know, that just shuffles around the pages; but still, it shouldn't 
segfault.)
- Running this on a specific process, e.g. smartd (which runs as root,
  and happened to be PID 510 during my tests) also exhibits the bug.
- Running this on a specific "luser" process as non-root also exhibits the bug.
- Adding a bit of printf debugging reveals which process it's looking at when 
it crashes:
  Sample from three attempts: smartd (510), policykit (574), reportbug (22041), 
exim4 (907)
  I don't see any pattern.
- Recompiling from source (apt-get source and 'make' instead of using Debian 
tools)
  also segfaults.  I have the impression that it's more seldom, but that may be 
subjective.
- Running this in gdb apparently "fixes it".
  (Set a breakpoint on exit with 'run -p 510 -v', fetch a cup of hot chocolate,
  see that it doesn't crash even after a hundred runs.)
- Running this in valgrind apparently "fixes it".
- Apparently valgrind and gdb change the timing a bit, and the segfault is due 
to a race
  condition of some kind.  That could even explain the slight increase in 
reliability after adding
  printf's into the loop of 'pagein_all_procs'.
- If that's the case, then '--show-mismatched-frees=no --keep-stacktraces=none 
--leak-resolution=low'
  doesn't make valgrind fast enough to cause the segfault there.
- Doing some printf-debugging, it seems that it always crashes "towards the 
end", but still in 'pagein_proc'.
  Any further printf-debugging slows the program down sufficiently to prevent 
it from crashing.

What else could I test?

Cheers,
Ben Wiederhake

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

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

Versions of packages pagein depends on:
ii  libc6  2.24-11

pagein recommends no packages.

pagein suggests no packages.

-- no debconf information

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

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

Versions of packages pagein depends on:
ii  libc6  2.24-11

pagein recommends no packages.

pagein suggests no packages.

Bug#864023: file: buggy magic: FLIF image dimensions misdetected

[Ben Wiederhake]

Package: file
Version: 1:5.30-1
Severity: minor

Dear Maintainer,

I created a 4096x4096 file in the FLIF format, and `viewflif` agrees that the 
image
has the dimensions 4096x4096.

EXPECTED output:
$ file output*
output.flif:FLIF image data, 4096x4096, 8-bit/color, grayscale, 
non-interlaced
output_interlaced.flif: FLIF image data, 4096x4096, 8-bit/color, grayscale

ACTUAL output:
$ file output*
output.flif:FLIF image data, 40831x40831, 8-bit/color,, grayscale, 
non-interlaced
output_interlaced.flif: FLIF image data, 40831x40831, 8-bit/color,, grayscale

I'm not sure whether the superfluous comma is relevant.

I attach only the file `output_interlaced.flif`, as it is smaller,
and seems to have no impact on the bug.

In case you worry that output_interlaced.flif got corrupted in transit:
Nope, it really is supposed to have that weird, not-quite-regular
diagonals-and-boxes pattern.
$ sha224sum output_interlaced.flif 
2940529f84e42b63c50253fbf5ad91a438663977da62ce291bf7d899  output_interlaced.flif

In case you need any more information to reproduce this, I'd be happy to help.

Regards,
Ben

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

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

Versions of packages file depends on:
ii  libc6  2.24-10
ii  libmagic1  1:5.30-1
ii  zlib1g 1:1.2.8.dfsg-5

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#860057: intltool-debian: Unescaped left brace in regex is deprecated

[Ben Wiederhake]

Package: intltool-debian
Version: 0.35.0+20060710.4
Severity: minor

Dear future Maintainer,

it seems that #787537 has come back.

Exact message:

Unescaped left brace in regex is deprecated, passed through in regex; 
marked by <-- HERE in m/\${ <-- HERE ?PACKAGE_NAME}?/ at 
/usr/bin/intltool-update line 1071,  line 101.

Note that this is a different set of lines (soecifically: 1 line)
 than the previous report.

This bug does not impede functionality.  I just wanted to document that
this is another issue one might want to work on.

Cheers,
Ben Wiederhake


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

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

Versions of packages intltool-debian depends on:
ii  gettext  0.19.8.1-2
ii  perl 5.24.1-2

intltool-debian recommends no packages.

intltool-debian suggests no packages.

-- no debconf information

Bug#851937: RFS: farbfeld/2.20170109-1 ITP

[Ben Wiederhake]

 This package contains tools for converting between farbfeld format
 and other image formats (png, jpeg, ppm, pam, git)


Minor nitpick, but since it also appears in the control file [1] and in 
a very prominent place:

I guess you meant to write "gif", as "git" is not an image format ;)

Keep up the good work!

Cheers,
Ben

[1] 
https://anonscm.debian.org/cgit/users/kaction-guest/farbfeld.git/tree/debian/control#n22

Bug#857553: xfce4-settings: "Disable Touchpad" duration is broken / rounded

[Ben Wiederhake]

Package: xfce4-settings
Version: 4.12.1-1
Severity: normal

Dear Maintainer,

in the tab "Touchpad", there is an option to disable the touchpad for
a certain amount of time after a keystroke happened.
Example values: 0.3s, 0.9s, 1.1s
These values are apparently floored (0.0 s, 0.0s, 1.0s, respectively).

Here are two scenarios that demonstrate the current behavior:

Scenario 1
Step to reproduce: set the slider to 0.9 seconds, open an editor of your choice,
  type something, try to wiggle the mouse
Expected behavior: Moving/clicking is blocked for 0.9 seconds
Actual behavior: Moving/clicking is not blocked at all, or "0.0 seconds"

Scenario 2
Step to reproduce: set the slider to 1.1 seconds, open editor, type, move mouse
Expected behavior: Moving/clicking is blocked for 1.1 seconds
Actual behavior: Moving/clicking is blocked for roughly 1 second.

So the general mechanism *does* work, it's just that apparently
the actual setting gets lost somewhere in transit.

This is frustrating, because I constantly touch the touchpad while typing,
which either messes up everything (because 0.9s becomes 0s), or I have
to wait for 1s every time I do anything with the keyboard
(because I want a setting lower than 1s).

And while I'm at it, here's a wishlist for a totally different functionality:
- Only clicks should be blocked.  Movement-only doesn't interfere with typing,
  so I don't see this ever being useful.
- If the previous wish-item gets declined: If one starts moving during the
  "blocking" phase, it seems to stay in a "blocking" state indefinitely until
  I release the touchpad.  So whenever there's a false positive, I'm crrently
  forced to let go and try again when the 1 second is over.
  Ideally, this should not be necessary.

Current workaround:
Set it to 1 second and be frustrated that I can't use the touchpad half of the 
time.

Reproducible: always.

Below is the "System Information" as generated by 'reportbug' on
the affected system (running on i686).  So that information is reliable.

Please ignore any other meta-information (i.e., headers of this email),
as they are generated by my home system (running on amd64),
which does not have a touchpad to begin with.

I'm happy to provide any other information, try out preliminary patches,
or fiddle around with gdb if you tell me where to start, i.e., which process.

Cheers,
Ben

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

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

Versions of packages xfce4-settings depends on:
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.14-1
ii  libdbus-glib-1-2 0.108-2
ii  libexo-1-0   0.10.7-1
ii  libfontconfig1   2.11.0-6.7
ii  libgarcon-1-00.4.0-2
ii  libgarcon-common 0.4.0-2
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-2
ii  libnotify4   0.7.7-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libupower-glib3  0.99.4-4
ii  libx11-6 2:1.6.4-3
ii  libxcursor1  1:1.1.14-1+b1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  libxi6   2:1.7.9-1
ii  libxklavier165.4-2
ii  libxrandr2   2:1.5.1-1
ii  xfconf   4.12.1-1

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

xfce4-settings suggests no packages.

-- no debconf information

Bug#855955: aisleriot: Variants "Westhaven" and "Diamond-Mine" interfere: crash with wrong-number-of-args

[Ben Wiederhake]

Package: aisleriot
Version: 1:3.22.1-1
Severity: normal

Dear Maintainer,

first of all: I'm unable to run the program with LC_ALL=C, so I'm sorry that
I can only provide the German name.
The German names are "Westhafen" and "Diamantenmine", which translates to
"Westhaven" and "Diamonmine".

The error is an "unexpected scheme error", which appears to be a 
wrong-number-of-args exception.
If I read the stack trace correctly, then this is due to some remnant code from 
Diamondmine
calling into code from Westhaven.

Steps to reproduce:
- Start aisleriot
- Select "Diamondmine"
- Quit aisleriot (apparently it's necessary that the *starting* game is 
Diamondmine)
- Start aisleriot
- Play a full game (not sure in how far this is necessary, but if you play 
through
  a whole game then it *always* happens.)
- Select "Westhaven"

Expected behavior:
Westhaven starts.

Actual behavior, on my i386 system:
The canvas goes blank (well, background-green), a dialog opens up saying
"Ein Schema-Ausnahmefehler ist aufgetreten
Bitte melden Sie diesen Fehler an die Entwickler.
[Nicht melden] [Melden]"
which translates to something like:
"An unexpected scheme exception occurred
Please report this issue to the developers.
[Don't report] [Report]"
Those brackets are supposed to indicate buttons.

Actual behavior 2, on my amd64 system (used to generate this report) :
Westhaven appears to start normally, but within a few actions (1 or 2, 
typically),
the above-mentioned dialog pops up.

Clicking "Report" doesn't do anything, and on the console reports that 
"bug-buddy"
couldn't be launched, which I guess is their intended bug reporter.
Since there doesn't seem to be a package called "bug-buddy",
or any package containing a relevant file [1],
I can't use this (apparently desired) path for this bug report.

After dealing with this error, Westhaven loads successfully, but may 
intermittently
crash and restart (the particular game, not aisleriot as a whole) during 
operation.

Manual workaround:
Restart aisleriot so that Westhaven is selected from the very beginning.

Please find attached a generated crash report by aisleriot, on my amd64 system.
I assume that aisleriot attempted to forward these data to "bug-buddy".
It includes stacktraces which indicate that Diamondmine somehow calls into 
Westhaven,
up to impedance mismatch.

Cheers,
Ben Wiederhake

[1] 
https://packages.debian.org/search?suite=testing=any=filename=contents=bug-buddy


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

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

Versions of packages aisleriot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gconf-service3.2.6-4
ii  gconf2   3.2.6-4
ii  guile-2.0-libs   2.0.13+1-4
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgc1c2 1:7.4.2-8
ii  libgconf-2-4 3.2.6-4
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk-3-0   3.22.7-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  librsvg2-2   2.40.16-1
ii  libx11-6 2:1.6.4-3

Versions of packages aisleriot recommends:
ii  yelp  3.22.0-1

Versions of packages aisleriot suggests:
pn  gnome-cards-data  

-- no debconf information
Variation: westhaven
Scheme error:
(#f Wrong number of arguments to ~A (#) #f)
Scheme tag:
wrong-number-of-args

Backtrace:
In ice-9/boot-9.scm:
 160: 8 [catch #t # ...]
In unknown file:
   ?: 7 [apply-smob/1 #]
In ice-9/boot-9.scm:
 160: 6 [catch #t # ...]
In unknown file:
   ?: 5 [apply-smob/1 #]
In westhaven.scm:
 304: 4 [get-hint]
 271: 3 [tableau-to-tableau? 6 10]
In diamond-mine.scm:
 278: 2 [find-card 6 (12 0 #t)]
In ice-9/boot-9.scm:
 105: 1 [# 
wrong-number-of-args ...]
In unknown file:
   ?: 0 [apply-smob/1 # wrong-number-of-args ...]


Deck State:
Slot 0
(3 3 #f) ,(0 5 #f) ,(0 8 #f)
 ,(3 8 #f) ,(1 13 #f) ,(1 7 #f) ,(3 10 #f) ,(0 4 #f) ,(0 10 #f) ,(3 7 #f) ,(3 
1

Bug#836340: libboost1.61-dev: Forward-declaration breaks int128 auto-detect, at least optional_fwd.hpp

[Ben Wiederhake]

Package: libboost1.61-dev
Version: 1.61.0+dfsg-2.1
Severity: important

Dear Maintainer,

here is the simplest failing example I could create:

#include 
#include 
int main() { return ; }

Compile like this:
clang++ -std=c++11 test.c
# OR
g++ -std=c++11 test.c

Expected behavior:
Compiles without error.

Actual behavior:
Does not compile.

First error from clang++:
In file included from test.cpp:2:
In file included from /usr/include/boost/optional.hpp:15:
In file included from /usr/include/boost/optional/optional.hpp:35:
In file included from
/usr/include/boost/type_traits/type_with_alignment.hpp:12:
In file included from /usr/include/boost/type_traits/is_pod.hpp:14:
In file included from /usr/include/boost/type_traits/is_scalar.hpp:12:
In file included from /usr/include/boost/type_traits/is_arithmetic.hpp:12:
/usr/include/boost/type_traits/is_integral.hpp:75:38: error: no member named
'int128_type' in namespace 'boost'
template<> struct is_integral : public true_type{};
  ~~~^

Apparently, the OpenBSD people have/had the same issue [1], which goes like
this:
(summary of link)
boost does not like mixing different compilers at build and run time.
Building boost with some gcc that doesn't support __int128 results in a
boost/config/user.hpp missing the "BOOST_HAS_INT128" define.
Then, boost/config/compiler/*.hpp re-enables it, but boost/config/suffix.hpp
doesn't catch wind of this.

Quick and dirty manual workaround:
echo '#undef __SIZEOF_INT128__' | sudo tee -a
/usr/include/boost/config/user.hpp
to enable it permanently.

I mark this as 'important', because this disrupts compilation for anyone using
forward-declarations, anywhere.  Feel free to downgrade this report if it
doesn't.

Cheers,
Ben Wiederhake

[1] http://openbsd-archive.7691.n7.nabble.com/devel-boost-fix-error-no-member-
named-int128-type-in-namespace-boost-td297541.html



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

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

Versions of packages libboost1.61-dev depends on:
ii  libstdc++-5-dev [libstdc++-dev]  5.4.1-1
ii  libstdc++-6-dev [libstdc++-dev]  6.1.1-11

libboost1.61-dev recommends no packages.

Versions of packages libboost1.61-dev suggests:
ii  libboost-atomic1.61-dev   1.61.0+dfsg-2.1
ii  libboost-chrono1.61-dev   1.61.0+dfsg-2.1
pn  libboost-context1.61-dev  
pn  libboost-coroutine1.61-dev
ii  libboost-date-time1.61-dev1.61.0+dfsg-2.1
pn  libboost-exception1.61-dev
ii  libboost-filesystem1.61-dev   1.61.0+dfsg-2.1
pn  libboost-graph-parallel1.61-dev   
pn  libboost-graph1.61-dev
ii  libboost-iostreams1.61-dev1.61.0+dfsg-2.1
pn  libboost-locale1.61-dev   
pn  libboost-log1.61-dev  
pn  libboost-math1.61-dev 
pn  libboost-mpi-python1.61-dev   
pn  libboost-mpi1.61-dev  
pn  libboost-program-options1.61-dev  
pn  libboost-python1.61-dev   
pn  libboost-random1.61-dev   
ii  libboost-regex1.61-dev1.61.0+dfsg-2.1
ii  libboost-serialization1.61-dev1.61.0+dfsg-2.1
pn  libboost-signals1.61-dev  
ii  libboost-system1.61-dev   1.61.0+dfsg-2.1
pn  libboost-test1.61-dev 
ii  libboost-thread1.61-dev   1.61.0+dfsg-2.1
pn  libboost-timer1.61-dev
pn  libboost-wave1.61-dev 
pn  libboost1.61-doc  
pn  libboost1.61-tools-dev
pn  libmpfrc++-dev
pn  libntl-dev

-- no debconf information

Bug#835141: RFS: telegram-purple/1.3.0-1 [ITP] -- Purple plugin to support Telegram

[Ben Wiederhake]

Package: sponsorship-requests
Version: sponsorship-requests
Severity: wishlist

Dear mentors,

in this mail:
(1) Asking potential sponsor about state
(2) normal RFS stuff
(3) things where I need help


(1) @Josue Ortega:  Are you still interested in sponsoring this package?  If
not, no problem, just please say so :)


(2) normal RFS stuff:
I am looking for a sponsor for my package "telegram-purple":

 * Package name: telegram-purple
   Version : 1.3.0-1
   Upstream Author : Matthias Jentsch <mtthsjnt...@gmail.com>
 * URL : https://github.com/majn/telegram-purple
 * License : GPL2+
   Programming Lang: C
   Section : net

It builds those binary packages:

  telegram-purple - Purple plugin to support Telegram

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

https://mentors.debian.net/package/telegram-purple

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

dget -x https://mentors.debian.net/debian/pool/main/t/telegram-purple
/telegram-purple_1.3.0-1.dsc

Or if you prefer to view the tree:

https://github.com/BenWiederhake/telegram-purple/tree/debian-develop

The package is (of course) mostly lintian clean and passes several other tests.
- Lintian "spelling-error-in-binary":  it's in a debug message of tgl.
- Lintian "hardening-no-bindnow":  see below

There is no pidgin-packaging team, otherwise I would have contacted
them nearly a year ago.

Please read README.source for some packaging choices.

Changes since the last upload (February 2016):
- new upstream version (finally! :D)
- bump standards from 3.9.6.0 to 3.9.8.0 (no-op)
- simplify orig-tar generation (upstream support)
- check for any changed copyrights (removal of "rawtar" process)
- reduce and fix d/docs
- update README.source ('make dist' and typos)
- update dev chat link in d/upstream/metadata


(3) Things where I need help:

The suggested fix for "hardening-no-bindnow" (namely, `hardening=+all`,
which inserts a `-fPIE`) breaks the build, as we need to build an
intermediate shared library, tgl, which can't work with PIE.  The
failing call to gcc looks like this:
gcc -shared -o libs/libtgl.so objs/${lot-of-objects}.o -fPIE -pie \
  -Wl,-z,relro -Wl,-z,now -L/usr/lib/${and/so/on} -rdynamic -ggdb -lz
-lgcrypt
/${path/to}/Scrt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
Since technically that file doesn't need to be built, the final
shared library (would) also fails:
gcc -shared -o bin/telegram-purple.so objs/${lots}.o tgl/libs/libtgl.a \
  -fPIE -pie -Wl,-z,relro -Wl,-z,now -L${paths} -l${things} -rdynamic -ggdb
Being a shared library, there naturally is no `main`, and a shared library
shouldn't be compiled with -fPIE.  Thus, I ignore this warning.

QA on mentors claims that the watchfile isn't valid:
A watch file is present but doesn't work
- Scanning for watchfiles in .
- Found watchfile in ./debian
- Scan finished
I can't reproduce this on my local 'testing' installation, nor
'unstable' chroot, as `./debian/rules get-orig-source` works as
expected, and I don't know QA's exact invocation of uscan, or the
error they see.

Regards,
Ben Wiederhake

Bug#833793: ITP: telegram-purple -- Adds support for Telegram to libpurple

[Ben Wiederhake]

Package: wnpp
Severity: wishlist
Owner: Ben Wiederhake <benwiederhake.git...@gmx.de>

* Package name: telegram-purple
  Version : 1.3.0
  Upstream Author : Matthias Jentsch <mtthsjnt...@gmail.com>
* URL : https://github.com/majn/telegram-purple
* License : GPL2+
  Programming Lang: C
  Description : Adds support for Telegram to libpurple

This provides a libpurple plugin that allows e.g. pidgin to
use Telegram (telegram.org) as a backend.

This package is relevant, because currently users would have to choose between:
- Not using Telegram at all
- Using the official Telegram client (which is considered annoying, because
users want to keep ONE im client with ALL accounts)
- Downloading, compiling, installing directly from source (which is annoying
because that's what the debian repo is for)

I personally use it, and several friends of mine. I participated in making it
ready for Debian (e.g. cleared a GPL-violation, cleaned up the build system).
I will continue to use and maintain this package, because I rely on being
able to be reachable via Telegram via Pidgin.

There are other packages (all in RFP state) that provide similar functionality:
- "tg", which is called upstream "telegram-cli", is a CLI for communicating
with telegram. This serves the need of those who EXCLUSIVELY use telegram. I
don't fall into this group.
- "telegram", which is a RFP of the official client. Same problem: This serves
the need of those who EXCLUSIVELY use telegram. I don't fall into this group.
- Note that this is a resurrection of #800771, as it timed out.

You might notice that tg (telegram-cli) and telegram-purple both use the same
basic library: libtgl ( https://github.com/vysheng/tgl )
It is not meaningful to ship that package separately as a "shared library"
(e.g.
"libtgl.so").  The rationale for this and other packaging choices can be
found in `debian/README.source`.

Just to reassure: upstream of telegram-purple (= Matthias Jentsch) is very
willing to see telegram-purple accepted in Debian.

Proposed maintainers:
- Ben Wiederhake (absolutely no experience in maintaining a Debian package)

If you intend to check out the source on GitHub, please notice that this
project makes use of git submodules *within* git submodules, and thus you
need to do "git clone --recursive https://github.com/majn/telegram-purple;

The current efforts of "Debianization" can be found at this branch:
https://github.com/BenWiederhake/telegram-purple/tree/debian-develop/

You might notice that 1.3.0 isn't released yet -- that's because it truely
isn't.  However, it's stable, and they/we are about to release, and I think
there's nothing essential missing in `debian/`, so I might be able to RFS
within a day after release of 1.3.0.

Regards,
Ben

Bug#830509: #830509: python-gtkspellcheck is outdated -> Up for adoption?

[Ben Wiederhake]

Dear MIA-team,

tl;dr: old maintainer appears inactive, I'd like to initiate the 
MIA-process, take over, and update the package.


it appears to me that the maintainer of "python-gtkspellcheck", namely 
Carlos Miguel Jenkins Pérez <car...@jenkins.co.cr> (who receives this 
mail due to the bug-CC), has gone missing in action.


So here's my summary according to the guide [1] for this situation:
- "they just need[ed] a reminder" -> False, as direct contact failed.
- "they just need[ed] a reminder" -> False, as direct contact by 
Maximilian Köhl (upstream author of python-gtkspellcheck) failed.
- "they just need[ed] a reminder" -> False, as opening yet another bug 
failed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830509
- "MIA Scripts" [2] -> I didn't intend to do any of these, although I 
have send the "initial" mails (because I think that's more polite) and 
created the bug (ditto).
- echelon ->  I assume that Carlos Pérez is not a registered DM. 
Neither am I, so 'm not sure.
- "number of packages this maintainer is responsible for" -> 1, only 
python-gtkspellcheck
- "any RC bugs that have been open for ages?" -> Not RC, but an 
"important" one since Feb 2016, and a "normal" one since Sep 2015.
- "whether the packages have been NMUed" -> Yes, once, in order to fix 
some serious issue.  The last NMUer made it clear that he is not 
interested in maintaining the package. [3]
- "Is there any activity of the maintainer outside of Debian?" -> A 
Google search for any activity after 2015 comes up clear [4].  There's 
some activity on GitHub and StackOverflow, though, so I assume/hope he's 
well, and just not interested in python-gtkspellcheck anymore.
- "you need to find and contact the Debian developer who has actually 
uploaded the package" -> not sure how to do that :(


Some context:
I'm primarily interested in seeing the package updated (as reportbug 
depends on it, and I think it's a nice thing).  So if Carlos Pérez can 
do another upload, I'd welcome him back :)
If that doesn't work out (and it looks like it won't), I'd like to take 
over the package (which involves getting Carlos Pérez marked as MIA), 
and upload a newer version of python-gtkspellcheck.


Cheers,
Ben Wiederhake

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#mia-qa

[2] https://wiki.debian.org/qa.debian.org/MIATeam
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830509#15
[4] 
https://www.google.com/search?q=%2BCarlos+Miguel+Jenkins+%2BP%C3%A9rez+after%3A2015=utf-8=utf-8

Bug#830509: Fwd: python-gtkspellcheck: Debian version is outdated -> Up for adoption?

[Ben Wiederhake]

CC last NMU uploader

 Weitergeleitete Nachricht 
Betreff: python-gtkspellcheck: Debian version is outdated -> Up for 
adoption?

Datum: Fri, 08 Jul 2016 20:13:37 +0200
Von: Ben Wiederhake <benwiederhake.git...@gmx.de>
An: Debian Bug Tracking System <sub...@bugs.debian.org>

Package: python-gtkspellcheck
Version: 3.0-1.1
Severity: important

Dear Maintainer,

I discovered that this package is actually pretty outdated: current is 
4.0.3.

At least one of the b.d.o bugs have already been fixed upstream.

I'm interested in packaging a newer version for Debian.  However, before I
start with that, I'd like to hear whether you (or the uploader of the 
last NMU)

are interested in updating the packaging yourself.

I'm also creating a public bug in case I need the MIA-team in the long run.

Cheers,
Ben Wiederhake

Bug#830509: python-gtkspellcheck: Debian version is outdated -> Up for adoption?

[Ben Wiederhake]

Package: python-gtkspellcheck
Version: 3.0-1.1
Severity: important

Dear Maintainer,

I discovered that this package is actually pretty outdated: current is 4.0.3.
At least one of the b.d.o bugs have already been fixed upstream.

I'm interested in packaging a newer version for Debian.  However, before I
start with that, I'd like to hear whether you (or the uploader of the last NMU)
are interested in updating the packaging yourself.

I'm also creating a public bug in case I need the MIA-team in the long run.

Cheers,
Ben Wiederhake

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

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

Versions of packages python-gtkspellcheck depends on:
ii  python  2.7.11-2
ii  python-enchant  1.6.6-2
ii  python-gi   3.20.1-1
ii  python-gtk2 2.24.0-4

Versions of packages python-gtkspellcheck recommends:
ii  iso-codes  3.68-1

python-gtkspellcheck suggests no packages.

Bug#825169: mps-youtube: I get KeyError: 'dashmpd' when trying to view or download some videos

[Ben Wiederhake]

Package: mps-youtube
Version: 0.2.5-5
Followup-For: Bug #825169

Hello,

I run into the same problem.  Bump!

Here's a slightly different stacktrace:

Exception in thread Thread-2:   
  
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/mps_youtube/main.py", line 3497, in 
preload
stream = get_streams(song)
  File "/usr/lib/python3/dist-packages/mps_youtube/main.py", line 345, in 
get_streams
p = get_pafy(vid, force=force, callback=callback)
  File "/usr/lib/python3/dist-packages/mps_youtube/main.py", line 314, in 
get_pafy
p = pafy.new(item.ytid, callback=callback_fn)
  File "/usr/lib/python3/dist-packages/pafy/pafy.py", line 148, in new
return Pafy(url, basic, gdata, signature, size, callback)
  File "/usr/lib/python3/dist-packages/pafy/pafy.py", line 866, in __init__
self.fetch_basic()
  File "/usr/lib/python3/dist-packages/pafy/pafy.py", line 892, in fetch_basic
smaps, js_url, mainfunc, dashurl = get_js_sm(self.videoid)
  File "/usr/lib/python3/dist-packages/pafy/pafy.py", line 481, in get_js_sm
dash_url = stream_info['dashmpd']
KeyError: 'dashmpd'


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

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

Versions of packages mps-youtube depends on:
ii  ffmpeg 7:3.0.2-4
ii  mpv0.14.0-1+b2
ii  python33.5.1-4
ii  python3-pafy   0.3.80-1
ii  python3-pkg-resources  20.10.1-1.1
pn  python3:any

Versions of packages mps-youtube recommends:
ii  libnotify4  0.7.6-2
ii  xclip   0.12+svn84-4

mps-youtube suggests no packages.

-- no debconf information

Bug#800771: telegram-purple package has been removed from Mentors

[Ben Wiederhake]

Control: close -1
Control: thanks

Am 02.06.2016 um 05:25 schrieb mentors.debian.net:

Your package telegram-purple all versions has been removed from 
mentors.debian.net for the following reason:

Your package found no sponsor for 20 weeks

Thanks,


As there is no upstream activity (partly my fault, sorry), I'm closing 
this ITP and RFS.


Regards,
a somewhat sad Ben

Bug#809623: RFS: telegram-purple/1.2.5

[Ben Wiederhake]

It *is* backward-compatible, but now a freshly-introduced
turns-out-to-be-big feature is missing.


Here I was referencing the "new" channels and super-groups, which still 
aren't implemented in telegram-purple, because Matthias hasn't had 
enough time for that yet (and I don't have any time at all).


This is made worse by the fact that Telegram released or intends to 
release a new feature: editable chat messages.  This will cause even 
more problems, since libpurple sinply doesn't have any API for that.



Is anything happening here?
Months passed since last email.


In short: no, nothing to see here.

If anyone is willing to work on libtgl's (the vysheng fork) missing API 
for channels (which is the main thing holding up 1.3.0), go for it and 
implement it.  Then implement 1.3.0.  If you do that, I'm more than 
willing to help with the Debianization and maintain it for quite a while :P


Sorry.  For now, you *could* clone and build from the github "dev-1.3.0" 
branch, if you keep in mind that support for super-groups and channels 
is incomplete (some messages may be silently dropped; some may be 
duplicated).  Or just clone and build from master, which is stable (but 
doesn't support super-groups or channels at all).


Regards,
Ben

Bug#820950: splint: Can't handle macros in format specifiers

[Ben Wiederhake]

Package: splint
Version: 3.1.2.dfsg1-2
Severity: normal

Dear Maintainer,

using any printing macro of inttypes.h breaks parsing and therefore splint.

Steps to reproduce: run splint on the attached file.

Expected behavior: output some warnings or maybe even say "there are no
warnings"

Actual behavior:
"""
demo.c:7:28: Parse Error. (For help on parse errors, see splint -help
   parseerrors.)
*** Cannot continue.
"""

Note that apparently, the parser starts at the '%' in the string and doesn't
notice that the string ends.

This means that parsing is *also* broken for a different, but recoverable
scenario if the "main specifier" is outside the macro, e.g.:
"""
#define MY_WIDTH "8"
printf("I am %0" MYWIDTH "d years old", -1);
"""

Regards,
Ben Wiederhake



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

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

Versions of packages splint depends on:
ii  libc62.22-5
ii  splint-data  3.1.2.dfsg1-2

splint recommends no packages.

Versions of packages splint suggests:
pn  splint-doc-html  

-- no debconf information
#include 
#include 

int main(void) {
printf("I am %" PRIdMAX " years old.\n", 1337L);
return 0;
}

Bug#817913: bpython: Keys not recognized: Home, End, Delete

[Ben Wiederhake]

Package: bpython
Version: 0.15-2
Severity: normal

Dear Maintainer,

when pressing any of the Home, End, Delete keys on the keyboard, nothing
happens. This is very annoying as it strongly limits the way I can edit the
input line.

This issue looks like it's already known and resolved(?) upstream [1], even in
the same version [2] as I have installed (?!), but I still observe the buggy
behavior.

The corresponding github-issue for the curtsies backend [3] seems to have been
fixed a while ago, but I'm unable to determine whether my installed version
"0.2.6-1" is up-to-date, as the github repo doesn't contain any version strings
that I can find.

I don't quite understand what's happening.

So my question is simply: Is this behavior known? Can I somehow help in
investigating this?

Cheers,
Ben Wiederhake

[1] https://github.com/bpython/bpython/issues/490
[2] https://github.com/bpython/bpython/issues/490#issuecomment-77897089
[3] https://github.com/thomasballinger/curtsies/issues/78



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

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

Versions of packages bpython depends on:
ii  python-curtsies   0.2.6-1
ii  python-greenlet   0.4.9-1
ii  python-pkg-resources  18.8-1
ii  python-pygments   2.1+dfsg-1
ii  python-requests   2.9.1-2
ii  python-six1.10.0-2
pn  python:any

Versions of packages bpython recommends:
pn  python-urwid 
pn  python-watchdog  

Versions of packages bpython suggests:
pn  python-jedi 
pn  python-twisted  

-- no debconf information

Bug#800771: Please don't package this software

[Ben Wiederhake]

Hello,


I think no Telegram client should be present in Debian repositories:


Null.


Telegram protocol is dangerous.


No.


* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767418#32


That's not up to you to decide.
We don't force anyone to use Telegram.


* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737563#30


Void.
This is not the Android app.

I do not appreciate your input.

With regards,
Ben Wiederhake

Bug#817791: check-all-the-things: [shellcheck] and [checkbashisms] should check all shell scripts

[Ben Wiederhake]

Package: check-all-the-things
Version: 2015.12.10
Severity: normal
Tags: patch

Hello,

currently, checkbashisms and shellcheck only look for files ending in '.sh'.
However, there are people who believe that executables should not be named
after the language in which they're currently implemented. For example, there
is "check-all-the-things" but not "check-all-the-things.py". Personally, I
advocate this, but for this report it only matters that a significant portion
of scripts does not end in '.sh'.

Using the existing syntax of catt, it's rather easy to extend the checks, and
filter by "file | grep | cat". Please see below for example runs on some
project I'm working on.

Impact:
- positive->negative can only occur for files whose name end in '.sh' but are
not shell scripts. I consider this a good thing, but I'm not sure why this
would ever happen.
- negative->positive can only occur for files whose name does NOT end in '.sh',
but ARE shell scripts, and DO trigger warnings/errors in the linting tools.
That's the point of this patch, so it's a good thing, too.

Is there a linter for the checks?
Should I adapt other checks, too?
In how far does this affect #791722, which seems to revolve mostly around
python scripts?

Cheers,
Ben Wiederhake



user@machine:~/workspace/telegram-purple$ # Run installed, non-patched version
on some project
user@machine:~/workspace/telegram-purple$ check-all-the-things --checks
=checkbashisms --checks +shellcheck
Skipped and hidden checks:
- cmdline disabled check: 7z-test acheck ansible-lint appstream-util-validate
appstreamcli-validate bashate bfbtester ...
- dangerous check: bfbtester perl-b-lint perl-syntax-check
- help needed: acheck ansible-lint appstream-util-validate appstreamcli-
validate build-log-scanner cbmc chk-origtargz ...
- no matching files: 7z-test bfbtester blhc build-log-errors build-log-warnings
bzip2-test cabal chk-origtargz ...
- no output: checkbashisms shellcheck



user@machine:~/workspace/telegram-purple$ # Run local, patched version on some
project
user@machine:~/workspace/telegram-purple$ ../check-all-the-things/check-all-
the-things --checks =checkbashisms --checks +shellcheck
$ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name .hg -o
-name _darcs -o -name _FOSSIL_ -o -name .sgdrawer -o -name configure -o -name
config.status -o -name config.sub -o -name config.guess -o -name install-sh -o
-name install.sh \) -prune -o -type f -print0 | xargs -0 file -F "   " -N |
grep -a 'shell script' | cut -f 1 | xargs -d"\n" --no-run-if-empty
checkbashisms
possible bashism in ./commit.h.gen line 23 ('command' with option other than
-p):
if ! (command -v git && git status) >/dev/null 2>&1

$ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name .hg -o
-name _darcs -o -name _FOSSIL_ -o -name .sgdrawer -o -name configure -o -name
config.status -o -name config.sub -o -name config.guess -o -name install-sh -o
-name install.sh \) -prune -o -type f -print0 | xargs -0 file -F "   " -N |
grep -a 'shell script' | cut -f 1 | xargs -d"\n" --no-run-if-empty shellcheck

In ./commit.h.gen line 35:
GIT_COMMIT=`git rev-parse HEAD | cut -c1-10`
   ^-- SC2006: Use $(..) instead of legacy `..`.

In ./gen-origtar line 47:
TARNAME="telegram-purple_`git describe --tags | sed s/^v// `.orig.tar.gz"
 ^-- SC2006: Use $(..) instead of legacy `..`.

In ./gen-origtar line 49:
echo mv -f bin/result.tar.gz $TARNAME
 ^-- SC2086: Double quote to prevent globbing and
word splitting.

In ./gen-origtar line 50:
mv -f bin/result.tar.gz $TARNAME
^-- SC2086: Double quote to prevent globbing and word
splitting.

Skipped and hidden checks:
- cmdline disabled check: 7z-test acheck afl ansible-lint appstream-util-
validate appstreamcli-validate autodep8 bashate ...
- dangerous check: bfbtester perl-b-lint perl-syntax-check
- help needed: acheck ansible-lint cbmc checkmp3 chk-origtargz clang-check
clang-tidy cppclean doc8 embedding-restrictions ...
- no matching files: 7z-test acheck afl ansible-lint appstream-util-validate
appstreamcli-validate autodep8 bashate ...
>From 7f782a324333fce427d2369b7ec96ae99f61f8c5 Mon Sep 17 00:00:00 2001
From: Ben Wiederhake <benwiederhake.git...@gmx.de>
Date: Thu, 10 Mar 2016 12:11:54 +0100
Subject: [PATCH] Improve detection of shell scripts

Affects [checkbashisms] and [shellcheck]
---
 data/sh | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/data/sh b/data/sh
index 2389117..32469e6 100644
--- a/data/sh
+++ b/data/sh
@@ -4,13 +4,23 @@ command = sh -n {file}
 
 [checkbashisms]
 apt = devscripts
-files = *.sh
-command = checkbashisms {files}
+# TODO: replace not-dirs with --ignore option
+not-dirs = .git .svn .bzr CVS .hg _darcs _FOSSIL_ .sgdrawer
+# TODO: replace not-files with recursive option (#780197)
+n

Bug#816636: bash: Typo in German translation: "angegebeneb"

[Ben Wiederhake]

Package: bash
Version: 4.3-14+b1
Severity: minor
Tags: upstream

Dear Maintainer,

tl;dr: There's a minor typo in the German translation. While trying to submit a
patch for that, I noticed that bash fails the patch test. [3]

Here's the typo:

  $ echo $LANG
  de_DE.utf8
  $ help command
  command: command [-pVv] Kommando [Argument ...]
  Führt ein einfaches Kommando aus oder zeigt Informationen über Kommandos
an.
  Führt das Kommando mit den angegebeneb Argumenten aus, ohne
  [... Snip ...]

The typo is the non-word "angegebeneb", which should have been the word
"angegebenen".

So I tried to "apt-get source bash". It contains the translations, but says it
is actually managed by lauchpad's German translation team. Lauchpad itself
looks surprised by this. [0]

The Bazaar repo [1] doesn't contain any translations. Huh? Doesn't that mean
that the source package is incomplete?

The GNU Savannah page [2] says:
Anonymous clone:
git clone git://git.savannah.gnu.org/bash.git
  That would be great, but this doesn't actually allow anonymous clones. Also,
all mailing lists (including the help and support mailing list) seem to reject
mails from unknown senders, so I can't ask there for help. Thus, I have to go
to the gitweb page and use the link displayed there to 'git clone'. Yay. But
this fails the patch test [3]. Can I ask you to talk to them about this?

The GNU Savannah repository [4] seems to consist of snapshots automatedly
gathered from a different repository, without any explanation where to find the
actual sources. I feel like going down a rabbit hole.

I tried using bashbug, but it appears that the mail never got sent to "bug-
b...@gnu.org,b...@packages.debian.org", although it sent it would.

I give up. Someone else can fix that typo.

Cheers,
Ben Wiederhake


[0]: https://translations.launchpad.net/gnubash
[1]: http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian
[2]: https://savannah.gnu.org/git/?group=bash
[3]: https://opensource.org/blog/ThePatchTest
[4]: http://git.savannah.gnu.org/r/bash.git

-- System Information [Edited]:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)

Bug#809623: RFS: telegram-purple/1.2.5

[Ben Wiederhake]

Hey there,


Well, that didn't work. Also, see below. As it turns out, pushing 1.2.5
into Debian right now would be a bad idea.


again, if the problem is on Windows, I don't really care.


We're not entirely sure about that; and 1.3.0 isn't ready yet.


Due to Telegram cranking out unexpected features that break everything,
we won't push 1.2.5 into Debian anyway, so that's why I don't bother
with another RFS yet.


as you wish, just be aware that we can break the freeze if needed, just
speed up the fixes :)


Wow, thanks!
But I'll decline for this time. Version 1.2.5 doesn't support 
channels/supergroups, and letting all telegram-enthusiasts run against 
the wall called "Yeah we promise it'll be in the next release for sure I 
swear" is a bad idea. So it's even more waiting.



(with telegram changing API/ABI it becomes difficult to make it suitable
for stable...)


It *is* backward-compatible, but now a freshly-introduced 
turns-out-to-be-big feature is missing.


Regards
Ben

Bug#809623: Fwd: Re: Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

(For completeness: this is the mail to which Gianfranco Costamagna 
responded. This mail contains no new information.)



 Weitergeleitete Nachricht 
Betreff: Re: Bug#809623: RFS: telegram-purple/1.2.3-1
Datum: Wed, 13 Jan 2016 21:40:27 +0100
Von: BenWiederhake.GitHub 
An: Gianfranco Costamagna 

Hello,


My script would probably do the following thing:
- delete the file fetched by uscan, since it's utterly incomplete
- use the upstream version to clone (as in git-clone) the repository
- ./configure && make dist || (echo "Too old upstream version; doesn't
support orig tarballs yet."; exit 1)
- delete all temporary files
Ugh.


seems an overkill :)


Seems like it, true, but sadly is necessary. The package is in version
control, and unless we provide pre-bundled origtars somewhere (which
won't happen), this has to build the origtar by invoking "make dist" in
the source tree.


And all that so that someone can say "dh get-orig-source".
So, who does this? (And can I assume git to be installed? I don't like
having such a big b-d ...)


git is needed for everybody who wants to work on Debian, not needed
to be a b-d :)


Now this is getting absurd: the whole point of dh get-orig-source is to
support people for who "git pull" is too complicated. But suddenly I can
assume that git is installed, although git is not pulled by build-essential?

$ sudo pbuilder --login
(SNIP)
# apt-get install build-essential
[SNIP]
# git --version
-bash: git: command not found


In short, the reason is: tgl ("the" submodule) is way too unstable and
volatile to ever be packaged separately.


this makes sense even if it should be avoided, but it is up to your sponsor
that part :)


Well, either that, or roughly 8 packages that are absolutely and utterly
useless building libtgl. (I'm not overestimating! 3 packages for
tl-parser and tgl each, plus 2 packages for "generate")

I agree with you that this should be avoided at *most* costs, but not at
*all* costs.

Regards,
Ben

Bug#800771: ITP: telegram-purple -- Adds support for Telegram to libpurple

[Ben Wiederhake]

Since there's somewhere a guideline saying that we should sometimes post
updates:

In the RFS thread it seemed to me that "dh get-orig-tar" is highly 
desirable. This delays it a bit. Also, worked on 1.3.0 (far from ready, 
improved build system) and 1.2.5 (released).



- Translation is coming along nicely, but we still desparately need
Russion and Brazilian translators:
https://www.transifex.com/telegram-purple-developers/telegram-purple/


For 1.3.0, this will go horribly bad, and we will have to reduce the 
number of translations. Sorry, but if nobody updates translations we 
have to remove them.


This is NOT a call for help, just a "report".

Cheers,
Ben Wiederhake

Bug#810976: [uscan] Ignores non-zero exitcode of "action"

[Ben Wiederhake]

Package: devscripts
Version: 2.15.9
Severity: normal
File: /usr/bin/uscan

Dear Maintainer,

when using a watchfile with an action, the exit-code is ignored.
This is problematic, because if the "action" is required to produce a working
orig tarball, this silently fails.

Here's the invocation of uscan I used:

uscan --noconf --verbose --rename --destdir=/home/user/workspace/telegram-
purple \
  --check-dirname-level=0 --force-download --download-version
"1.2.5~beta" \
  /home/user/workspace/telegram-purple/debian

Here's the actual behavior, truncated to the relevant part:

-- Executing user specified script
 /bin/false --upstream-version 1.2.5~beta /home/eispin/workspace
/telegram-purple/telegram-purple_1.2.5~beta.orig.tar.gz
-- Scan finished
user@xpected:~/workspace/telegram-purple$ echo $?
0

Here's what I would have liked to see:

-- Executing user specified script
 /bin/false --upstream-version 1.2.5~beta /home/user/workspace
/telegram-purple/telegram-purple_1.2.5~beta.orig.tar.gz
-- Scan aborted: user specified script failed
user@xpected:~/workspace/telegram-purple$ echo $?
1

(or something like it)

The BTS doesn't know anything about this, and 2.15.10 (unstable) doesn't seem
to fix this, according to the changelog.

Regards,
Ben Wiederhake


-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
DEBUILD_LINTIAN_OPTS="-EiI --pedantic --show-overrides"
DEBSIGN_KEYID="CB6A 2523 BF57 5A47 4352  0FA7 2DAE 208A 6034 F1B9"
DEBEMAIL="benwiederhake.git...@gmx.de"
DEBFULLNAME="Ben Wiederhake"

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.4
ii  libc62.21-6
ii  perl 5.22.1-3
ii  python3  3.4.3-7
pn  python3:any  

Versions of packages devscripts recommends:
ii  at  3.1.18-2
ii  curl7.46.0-1
pn  dctrl-tools 
ii  debian-keyring  2015.11.30
ii  dput-ng [dput]  1.10
pn  equivs  
ii  fakeroot1.20.2-1
ii  file1:5.25-2
ii  gnupg   1.4.20-1
pn  libdistro-info-perl 
ii  libencode-locale-perl   1.05-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
pn  libsoap-lite-perl   
ii  liburi-perl 1.69-1
ii  libwww-perl 6.15-1
ii  lintian 2.5.39.1
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.25-2
ii  sensible-utils  0.0.9
ii  strace  4.10-3
ii  unzip   6.0-20
ii  wdiff   1.2.2-1+b1
ii  wget1.17.1-1
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
[SNIP -- irrelevant]

Bug#810292: gettext-lint: Only check spellings against installed dictionaries

[Ben Wiederhake]

Package: gettext-lint
Version: 0.4-2.1
Severity: normal

Control: user check-all-the-thi...@packages.debian.org
Control: usertags -1 + false-positive
Control: affects -1 + check-all-the-things
Control: thanks


Dear Maintainer,

currently, there is no sanity check against the list of available dictionaries,
and apparently no limit in the amount of errors produced.

This has the undesired effect that every word for every language (for which I
don't have an appropriate dict installed) is reported as misspelled.

I'd like to suggest a new flag `--no-missing'. When this flag is set and
POFileSpell detects that a dictionary seems to be missing, only output a single
warning for that language, probably along the lines of:

  No dictionary found for language es_AR. You can specify additional
  dicts with the --dict=path/to/dict option.

With this flag, the output can be kept more concise and meaningful.
To reinforce the point: 1 warning among 100 false-positive warnings is useless.

I already reported the file upstream:
https://sourceforge.net/p/gettext-lint/bugs/4/
 but I want a bugreport in the BTS for the usertag.
The repository doesn't seem to have been active in the last 9 years.
Did I pick the correct source?

The source is in src/POFileSpell.in, which has only 216 lines
(195 according to sloccount).

Regards,
Ben Wiederhake

Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

- flawfinder yields too many results to be practical (~ 2460 lines). This is
mostly due to libtgl being written in a style that uses static arrays for
everything, including parsing and output.


I've been thinking of making the default for c-a-t-t to limit output
of checks by default, probably to around 10 lines.


Sounds good!


- The output of "POFileSpell" seems to depend on the local dictionaries. It
seems to flag every word in every language I don't speak. (~ 1640 lines)


This is correct, you obviously need to install the relevant
dictionaries for it to be useful.


How about an option that changes the following:
- Current: thousands of warning for French, because the French dict is 
missing.
- Suggested: single warning, saying "French dictionary not found 
(expected at /usr/share/some/where)"


But I guess this should be reported against POFileSpell, not c-a-t-t, right?


- "suspicious-source" works like a charm. It runs in a fraction of a second,
and outputs only a single line: "./tg-server.tglpub"
   That's absolutely correct! I like that program. (I'm not complaining, I'm
admiring the program. The file ./tg-server.tglpub is clearly documented in
the README.md, including a link to a side-project with the sole purpose of
reproducibly generating this single file for public sources.)


Hmm, are you sure?

pabs@chianamo ~/telegram-purple-1.2.3 $ grep tglpub README.md
pabs@chianamo ~/telegram-purple-1.2.3 $


*head-desk*

It looks like I wrote the documentation while tired.

$ grep tlgpub README.md
We no longer ship `tg-server.pub` (old format), but instead
   `tg-server.tlgpub` (new format). [snip]

Obviously, the spelling "tlg" is wrong, and should be "tgl". All files 
are named correctly. This will be fixed in the next upstream release.



After reading the source code I see that it is some sort of public key.


It is, basing on Telegram's public key. (Has to be requested by mail. 
Don't ask me why they had that idiotic idea.)
The tglpub file-format is easy enough to be written with nothing but a 
hexeditor; is clearly explained (just three big endian integers); comes 
along with a program that demonstrates how to generate the tglpub given 
the original pubfile.


In case you wonder why we don't just read the original pubkey: 
proprietary file format, and wanted to avoid using a function that 
smells like OpenSSL.



- The "Please add some upstream metadata" warning triggers. Since this is
not a scientific project, and there won't be any doi-references, I'm going
to ignore the warning. However, I'm going to use this to ask: Why is that a
warning? Why not include it in the build scripts of the deb-science
packaging team instead?


The upstream metadata stuff has nothing to do with science apart from
being initiated by the science team. Just include the parts that apply
to this package. I don't understand why so many people have this
misconception.


Because it's the first and only thing at which I looked when opening the 
page for the first few times. Now I finally actually read it (oh god, 
sorry dear author of the page). I included it into 1.2.4-2. (See 
separate mail.)



- The problem of bashisms relates to the program checkbashism, like
incompatibilities between make-implementations to checkgmakeism, a program
I'd like to see being written. I made up the name. I have no idea how to do
that. So far, we did it by trial and error, and change something whenever a
user complains. AFAIK, by now we only support gmake, due to the use of
"ifdef", which should be ".ifdef" in bsd-make:
https://github.com/majn/telegram-purple/issues/137#issuecomment-167970054


That would be a good check to have but for now I don't know of any
implementation or anyone interested in working on such a thing.


Sure, no pressure, just wanted to mention it, in case a 
Make-compatibility-guru reads along :P



Sorry for the wall of text, but you *did* ask for it :P


One goal of c-a-t-t is to expose more people to the tools, eventually
leading to better tools :)


I wasn't even remotely aware of the sheer flood of such tools, each of 
them doing different things, and then there's sanity check so basic that 
you didn't even need a "tool" for that and just used grep/find/etc. 
Thank you for the program, the work, the feedback :D


Regards,
Ben Wiederhake

Bug#809623: RFS: telegram-purple/1.2.4-1 [ITP]

[Ben Wiederhake]

Dear mentors,

I am looking for a sponsor for my package "telegram-purple"

 * Package name: telegram-purple
   Version : 1.2.4-2
   Upstream Author : Matthias Jentsch <mtthsjnt...@gmail.com>
 * URL : https://github.com/majn/telegram-purple
 * License : GPL2+
   Programming Lang: C
   Section : net

It builds those binary packages:

  telegram-purple - Purple plugin to support Telegram
  telegram-purple-dbg - Debug symbols, auto-generated by dpkg-buildpackage

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


  http://mentors.debian.net/package/telegram-purple

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

  dget -x 
http://mentors.debian.net/debian/pool/main/t/telegram-purple/telegram-purple_1.2.4-2.dsc


Changes since the last upload:
  - d/changelog collapsed
  - d/control fixes git url, explains name
  - d/rules cleaned up
  - d/README.source created with extensive documentation of packaging 
procedure and ~choices
  - checked with "check-all-the-things" that there are no critical 
bugs. All other things will be handled eventually in the next upstream 
version.

  - d/upstream/metadata added

I'm confused as to how to put a comment into the d/control file.
- A "raw" comment (line prefixed by the '#' character) is not 
machine-readable and will be ignored. Furthermore, it is deprecated by 
some tool (forgot which one).

- The Policy explicitly allows "X[BCS]*-Comment" fields:
  https://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7
  However, 'cme check dpkg' doesn't recognize this as valid.
  Not sure what to do, I'm going with X-Comment and #810023

Regards,
Ben Wiederhake

Bug#810023: libconfig-model-dpkg-perl: Does not recognize/allow user-defined fields as per §5.7

[Ben Wiederhake]

Package: libconfig-model-dpkg-perl
Version: 2.069
Severity: normal

Dear Maintainer,

I'm trying to package something for Debian and use (among other tools)
cme to make sure that my d/control is sane.

There is some issue with the package, which means I would like to put
a comment into d/control. However, this is deprecated by some tools,
and also a bad idea: YAML-comments are not readily machine-parsable.

Thus I was happy to see that §5.7 explicitly allows user-defined tags,
and mentions "X-Comment" as an example; so I believe I'm acting in the
intention of that Policy.

However, cme (a program that uses libconfig-model-dpkg-perl)
does not allow this:

$ cme check dpkg
In control binary:invalid: (function 'create_element') unknown element
'X-Comment'. Either your file has an error or Dpkg::Control::Binary model is
lagging behind. In the latter case, please submit a bug report or fix the
model. See cme man page for details.
Expected elements: 'Architecture','Multi-
Arch','Section','Priority','Essential','Depends','Recommends','Suggests','Enhances
','Pre-Depends','Breaks','Conflicts','Provides','Replaces','Built-Using
','Package-Type','Synopsis','Description','Homepage','Build-Profiles'

Please find a sample file attached.

Could this be changed so that user-defined tags
are recognized and handled as such?

Regards,
Ben Wiederhake

PS: In case anyone cares, it's about telegram-purple, RFS #809623 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809623#20



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

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

Versions of packages libconfig-model-dpkg-perl depends on:
ii  devscripts   2.15.9
ii  libapt-pkg-perl  0.1.29+b5
ii  libarray-intspan-perl2.003-1
ii  libconfig-model-perl 2.075-1
ii  libexporter-lite-perl0.06-1
ii  liblog-log4perl-perl 1.46-1
ii  libmouse-perl2.4.5-1+b1
ii  libparse-recdescent-perl 1.967013+dfsg-1
ii  libsoftware-license-perl 0.103010-4
ii  libtext-autoformat-perl  1.74-1
ii  libtext-levenshtein-damerau-perl 0.41-1
ii  liburi-perl  1.69-1
ii  libwww-perl  6.15-1
ii  lintian  2.5.39.1
ii  perl 5.22.1-3
ii  perl-modules-5.22 [libmodule-corelist-perl]  5.22.1-3

Versions of packages libconfig-model-dpkg-perl recommends:
pn  libconfig-model-tkui-perl  

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information
Source: invalid
Section: net
Priority: optional
Maintainer: Ben Wiederhake <ben.wiederh...@gmail.com>
Build-Depends:
 debhelper (>= 9)
Standards-Version: 3.9.6
Homepage: https://github.com/some/where
Vcs-Git: https://github.com/my/where
Vcs-Browser: https://github.com/my/where/tree/debian-develop

Package: invalid
Architecture: any
Depends:
 ${misc:Depends},
 ${shlibs:Depends}
Description: Invalid does nothing
 You shouldn't use this as your own. However, it has to look good for cme.
X-Comment: Traditionally, this would probably have been called 'hello-world',
 but I needed a reason to write a comment, so yeah.
 .
 This is a valid field as per Policy §5.7.
 ( https://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7 )

Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

Hi, I happen to be i18nspector upstream.


Wow! What a quick response, thank you :)


- i18nspector and Transifex (the service we use for our translation)
heavily disagree about how a po-file should look like,


Care to elaborate on how they "heavily disagree"?


I "only" refer to the pluralization form.


and how Russion plurals work(?!).


The Russian PO file reads:

Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 &&
n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9)
|| (n%100>=11 && n%100<=14)? 2 : 3);


This is copied verbatim from the Transifex service. I'm not competent 
enough in Russian to dare touching it. This discussion seems to lead to 
a bug in Transifex itself. I'll contact Transifex about this, linking to 
this discussion.



Even though I don't speak Russian, I can tell that this Plural-Forms
can't possibly be correct. Here 4 plural forms are declared, but the
expression never evaluates to 3.


Since it's just modular arithmetic, one can just parse the formula to 
fill out a 10x10 table as a "proof". I did that, and came to the same 
result as you do, without even looking at your program. (Originally I 
assumed a precedence error / parsing issue / whatever, so I didn't want 
to start reading C code ... sorry.)


For the record, here's my interpretation, with parenthesis added:

((n%10==1 && n%100!=11)
 ? 0
 : ((n%10>=2 && n%10<=4 && (n%100<12 || n%100>14))
? 1
: ((n%10==0 || (n%10>=5 && n%10<=9) || (n%100>=11 && n%100<=14))
   ? 2
   : 3)))

This rule can be written in regex as follows (note that there is an 
implicit "and not any of the above", although it doesn't make a difference):

- "[023456789]1" => "Transifex one"
- "[023456789][234]" => "Transifex few"
- "1.|.[056789]" => "Transifex many"
- else => "Transifex other"

In this form, it's rather easy to verify that "Transifex other" never 
happens. The names of the forms are based on what Transifex calls them.



I'm too lazy to make a mathematical proof that this the case, so instead
I wrote a small program that demonstrates it. Please see the attachment.
Let me know if the program ever stops. :-P


I'm going to recommend http://haroldbot.cloudapp.net/ for this, even 
though it fails with "Something went wrong" for all queries related to 
this. I have no idea why.



Now, it would be cool if i18nspector explained better what is wrong
here. [snip]  I hope to implement this in the future.


Sounds awesome! However, I was still able to understand that *something* 
about the expression was fishy, but didn't understand that i18nspector 
is able to detect issues like this. (Doesn't that essentially require a 
SAT-solver?)


([snip] other issues that need no response from my side.)

Regards,
Ben Wiederhake
PS: Juhani Numminen, I haven't ignored your mail, but my response to 
your mail is going to take longer. Sorry, and thanks for your detailed 
feedback!

Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "telegram-purple"

 * Package name: telegram-purple
   Version : 1.2.3-1
   Upstream Author : Matthias Jentsch <mtthsjnt...@gmail.com>
 * URL : https://github.com/majn/telegram-purple
 * License : GPL2+
   Programming Lang: C
   Section : net

It builds those binary packages:

  telegram-purple - Purple plugin to support Telegram

To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/telegram-purple

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

  dget -x http://mentors.debian.net/debian/pool/main/t/telegram-purple
/telegram-purple_1.2.3-1.dsc

I've been following the debian-mentors list for quite a while, so it's likely
that I made different mistakes :P
The package is (of course) lintian clean and passes several other tests.
There is no pidgin-packaging team, otherwise I would have contacted them months
ago.

Regards,
Ben Wiederhake

Bug#806526: hardening-includes: Typos in manpage

[Ben Wiederhake]

Package: hardening-includes
Version: 2.7
Severity: minor
Tags: newcomer

Dear Maintainer,

currently, the manpage for hardening-check contains a few typos and broken
sentences that make it hard to read.

These are what I found while reading it (via "man hardening-check") :

- Section "Fortify Source functions", sentence "This causes certain unsafe
glibc functions [sic]with their safer counterparts (e.g. strncpy instead of
strcpy)"
  -> Missing "to be replaced" at my mark?
- Same section, end of the sentence, "insteade[sic]"
  -> s/insteade/instead/
- All "-no*" options: "No[sic] not require that the checked binaries be built"
  -> Did you mean "Do not"?
- Why can't the program "codespell" find these typos? At the very minimum,
"insteade" should be detected. Resolving this might uncover further typos.
- Probably separate thing: What is "hardening-check.sh" do? It seems to
duplicate the functionality, contain a broken old version of the man page, and
is not in the BZR repository.

If the answer on most of those is "yes", I can try to make a patch for it.

Regards,
Ben Wiederhake



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

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

Versions of packages hardening-includes depends on:
ii  binutils  2.25.1-7
ii  make  4.0-8.2
ii  perl  5.20.2-6

hardening-includes recommends no packages.

hardening-includes suggests no packages.

-- no debconf information

Bug#801633: lintian: False positive of syntax-error-in-dep5-copyright with documentation example

[Ben Wiederhake]

Package: lintian
Version: 2.5.38
Severity: normal

Dear Maintainer,

I was trying to get an ITP submission lintian-clean, when I got stumped by a
very stubborn warning, even after reading every sentence in the packaging-
documentation on debian/copyright ever so carefully.

Then I tried the example from the documentation itself [1], and the warning
persists. I report this as a bug in lintian because I believe that lintian
should accept positive examples from the documentation without warning.

To reproduce, clone the given repo [2], and run:

$ lintian -EviIL +pedantic telegram-purple_1.2.2-1.dsc
[SNIP]
W: telegram-purple source: syntax-error-in-dep5-copyright line 18: Cannot parse
line "Copyright 2009, 2010 Angela Watts"
[SNIP]

Note that I intentionally emptied the *.orig.tar.gz, since the contents are
irrelevant to the warning. (The same warning is produced with and without the
original file.)

[1]: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0
/#copyright-field
[2]: https://github.com/BenWiederhake/lintian-copyright



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

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

Versions of packages lintian depends on:
ii  binutils   2.25.1-3
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.25-2
ii  gettext0.19.6-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.29+b3
ii  libarchive-zip-perl1.53-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdpkg-perl   1.18.3
ii  libemail-valid-perl1.196-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.3-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.3
pn  libperlio-gzip-perl 
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.1-3
ii  dpkg-dev   1.18.3
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   

Bug#801647: lintian: Warn on whitespace around name in changelog

[Ben Wiederhake]

Package: lintian
Version: 2.5.38
Severity: wishlist

debian/changelog is a partly automatically generated file, partly manually
edited.
I probably did something wrong to even notice this edge case, but still.

Given a debian/changelog that ends with, for example:

"""
 --  Hugues Morisset   Fri, 02 Oct 2015 14:13:47
+0100
"""

And given a debian/control that contains, among others:

"""
Maintainer: Hugues Morisset 
"""

Then lintian complains (correctly!) about the current version being a NMU,
i.e., changelog-should-mention-nmu and source-nmu-has-incorrect-version-number.

For a Debian newbie, this is very confusing.

To make it easier to resolve issues like this, I would like to "wish" for an
*additional* warning message like this:

"""
The most recent changelog entry is from " Hugues Morisset
". The control file lists "Hugues Morisset
" as a maintainer. These count as different people
only due to differing whitespace, even though the address is identical. If this
dissociation is unintended, please correct the whitespace issue in the
changelog.
"""

I'm horrible at designing warning messages, but I hope I could explain why,
what, and how this is happening; and why it's pretty unintuitive.

As indicated in the fictive warning message, I would suggest checking the "raw"
email address of the changelog against the "raw" email address of each
maintainer and uploader. If the address matches but the name doesn't, then the
packager most definitely did not intend this.



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

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

Versions of packages lintian depends on:
ii  binutils   2.25.1-3
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.25-2
ii  gettext0.19.6-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.29+b3
ii  libarchive-zip-perl1.53-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdpkg-perl   1.18.3
ii  libemail-valid-perl1.196-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.3-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.3
pn  libperlio-gzip-perl 
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.1-3
ii  dpkg-dev   1.18.3
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   

-- no debconf information

Bug#800576: gitk --all doesn’t work anymore in some locales

[Ben Wiederhake]

Package: gitk
Version: 1:2.6.1-1
Followup-For: Bug #800576

Just updated to the new version in testing (1:2.6.1-1), ran into this bug for
"gitk --all"

It seems to work for "gitk" though.



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

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

Versions of packages gitk depends on:
ii  git  1:2.6.1-1
ii  tk   8.6.0+8

gitk recommends no packages.

Versions of packages gitk suggests:
pn  git-doc  

-- no debconf information

Bug#800771: ITP: telegram-purple -- Adds support for Telegram to libpurple

[Ben Wiederhake]

Package: wnpp
Severity: wishlist
Owner: Ben Wiederhake <benwiederh...@gmx.de>

* Package name: telegram-purple
  Version : 1.2.1~beta3-1
  Upstream Author : Matthias Jentsch <mtthsjnt...@gmail.com>
* URL : https://github.com/majn/telegram-purple
* License : GPL2+
  Programming Lang: C
  Description : Adds support for Telegram to libpurple

This provides a libpurple plugin that allows e.g. pidgin to
use Telegram (telegram.org) as a backend.

This package is relevant, because currently users would have to choose between:
- Not using Telegram at all
- Using the official Telegram client (which is considered annoying, because
users want to keep ONE im client with ALL accounts)
- Downloading, compiling, installing directly from source (which is annoying
because that's what the debian repo is for)

I personally use it, and several friends of mine. I participated in making it
ready for Debian (e.g. cleared a GPL-violation). I will continue to use and
maintain this package, because I rely on being able to be reachable via
Telegram, and I rely on Pidgin.

There are other packages (all in RFP state) that provide similar functionality:
- "tg", which is called upstream "telegram-cli", is a CLI for communicating
with telegram. This serves the need of those who EXCLUSIVELY use telegram. I
don't fall into this group.
- "telegram", which is a RFP of the official client. Same problem: This serves
the need of those who EXCLUSIVELY use telegram. I don't fall into this group.

You might notice that tg (telegram-cli) and telegram-purple both use the same
basic library: libtgl ( https://github.com/vysheng/tgl )
You might want us to ship that package separately as a "shared library" (e.g.
"libtgl.so").
However, libtgl is in very volatile development, and upstream (= vysheng)
doesn't care much about ABI compatibility. Furthermore, it is reasonable to
assume that nobody (except those who develop both) will install telegram-cli
and telegram-purple simultaneously, so making it a shared library doesn't
really have much benefit here.
Just to reassure upstream of telegram-purple (= Matthies Jentsch) is very
willing to see telegram-purple accepted in Debian, too. ("too" because it's
already in Fedora.)

Proposed maintainers:
- Hugues Morisset (little experience in maintaining a Debian package)
- Ben Wiederhake (absolutely no experience in maintaining a Debian package)
We'd like to be co-maintainers.

If you intend to check out the source on github, please notice that this
project makes use of git submodules, and thus you need to do "git clone
--recursive https://github.com/majn/telegram-purple;

The current efforts of "debianization" can be found at:
- https://github.com/BenWiederhake/telegram-purple (branch "debian")
- https://github.com/izissise/telegram-purple (branch "debian")

Bug#799714: Suggested patches

[Ben Wiederhake]

Tags: patch

Sorry, it seems I had reportbug running with an outdated email address.
I am the original reporter.

Please find attached:
- a patch to fix the above-mentioned issue
- a patch to fix another issue ($pwd is probably rather long, so the 
line wrapping should consider that)


Here is a fork-able repo:
https://github.com/BenWiederhake/dh-make
A version with both commits squashed:
https://github.com/BenWiederhake/dh-make/tree/squashed

In case this is required: I'm willed to add a "Signed-Off-By" line to 
each commit, but it doesn't look like this is required.


A note on the commit messages: The singular/plural difference is 
intentional, as it is about one and two such messages respectively.


With regards,
Ben Wiederhake
>From 9a3c2ee99eefb10d96d8e850477dffa65dbf7bed Mon Sep 17 00:00:00 2001
From: Ben Wiederhake <BenWiederhake.GitHub@gmx>
Date: Mon, 21 Sep 2015 21:43:52 +0200
Subject: [PATCH 1/2] Beautify error message.

---
 debian/changelog |  4 
 dh_make  | 32 ++--
 dh_make.1|  9 +++--
 3 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 853f09d..4945ff0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
 dh-make (1.20150913) UNRELEASED; urgency=medium
 
+  [ Craig Small ]
   * Fixed LGPL comment
   * Added custom copyright template option
 
+  [ Ben Wiederhake ]
+  * Explain why version couldn't be parsed Closes: #799714
+
  -- Craig Small <csm...@debian.org>  Mon, 07 Sep 2015 21:12:25 +1000
 
 dh-make (1.20150601) unstable; urgency=medium
diff --git a/dh_make b/dh_make
index bca9e2f..26b77c2 100755
--- a/dh_make
+++ b/dh_make
@@ -399,11 +399,31 @@ sub get_package
 	my $pwd = ::cwd();
 	my $forced_package_version = "";
 	# May split the version out of the name
-	if ( ($main::forced_package_name) &&
-		($main::forced_package_name =~ /(.*)_([0-9][0-9a-zA-Z+.~-]*)$/))
-   	{
-		$main::forced_package_name = $1;
-		$forced_package_version = $2;
+	if ($main::forced_package_name)
+	{
+		if ($main::forced_package_name =~ /(.*)_([0-9][0-9a-zA-Z+.~-]*)$/)
+		{
+			$main::forced_package_name = $1;
+			$forced_package_version = $2;
+		} elsif ($main::forced_package_name =~ /(.*)_(.*)$/)
+		{
+			print <<"EOF";
+The directory name you have specified is invalid!
+It seems the _ format was attempted,
+since underscores are illegal in both package-name and version.
+Make sure that the version starts with a digit and contains only
+digits, lower and uppercase letters, dashes, or the signs plus, dot, tilde.
+
+Your current directory is $pwd, perhaps you could try going to
+directory where the sources are?
+
+Please note that this change is necessary ONLY during the initial
+Debianization with dh_make.  When building the package, dpkg-source
+will gracefully handle almost any upstream tarball.
+
+EOF
+			exit 1;
+		}
 	}
 	if ( ($forced_package_version ne "")
 	   	|| (
@@ -445,7 +465,7 @@ Debianization with dh_make.  When building the package, dpkg-source
 will gracefully handle almost any upstream tarball.
 
 EOF
-	 exit 1;
+		exit 1;
 	}
 	if (! ($main::package_name =~ /^[a-z0-9+.-]+$/))
	{
diff --git a/dh_make.1 b/dh_make.1
index 6c75fa7..8c88753 100644
--- a/dh_make.1
+++ b/dh_make.1
@@ -24,8 +24,13 @@ is a tool to convert a regular source code package into one formatted
 according to the requirements of the Debian Policy.
 .B dh_make
 must be invoked within a directory containing the source code, which must
-be named \-. The  must be all lowercase,
-digits and dashes. If the directory name does not conform to this scheme,
+be named \-.
+The  must be all lowercase,
+The  and 
+must be all lowercase,
+digits and dashes. The  can also contain digits, and the symbols
+plus, dot, tilde. The  must start with a digit.
+If the directory name does not conform to this scheme,
 you must rename it before using 
 .B dh_make.
 Alternatively, you may be able to use the \fB\-\-packagename\fR option to force 
-- 
2.5.1

>From 3c89ad8b44f5766672edcee757aa5a2ab7e36de9 Mon Sep 17 00:00:00 2001
From: Ben Wiederhake <BenWiederhake.GitHub@gmx>
Date: Mon, 21 Sep 2015 21:46:27 +0200
Subject: [PATCH 2/2] Beautify error messages.

---
 debian/changelog |  1 +
 dh_make  | 10 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 4945ff0..5df7dd2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,7 @@ dh-make (1.20150913) UNRELEASED; urgency=medium
 
   [ Ben Wiederhake ]
   * Explain why version couldn't be parsed Closes: #799714
+  * Fix linebreaks (expect $pwd to be long)
 
  -- Craig Small <csm...@debian.org>  Mon, 07 Sep 2015 21:12:25 +1000
 
diff --git a/dh_make b/dh_make
index 26b77c2..06c3ece 100755
--- a/dh_make
+++ b/dh_make
@@ -414,8 +414,9 @@ since underscores are illegal in both package-name and version.
 Make sure that th