Bug#1034268: cvc5: Please package the python modules

[Celelibi]

Source: cvc5
Severity: normal
X-Debbugs-Cc: celel...@gmail.com

Hello,
There are two Python API to CVC5. The base API that closely match the
C++ one, and the pythonic API.

The base API is part of the main repository and should be built
automatically with the rest of the code. I guess it could be packaged as
a separate python3-cvc5 package with very little effort.

The pythonic API is another repository and uses the base API.
https://github.com/cvc5/cvc5_pythonic_api

I don't think packaging the base API would be too much additional work,
since it's from the same source code that produces the packages cvc5,
libcvc5-dev, libcvc5-1 and libcvc5parser1.

Having the pythonic API would be even better, but not necessary.

Best regards,
Celelibi

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-security'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

-- no debconf information

Bug#1019415: qt.qpa.xcb: xcb_shm_create_segment() can't be called for size 17178820624

[Celelibi]

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

Dear Maintainer,

When running some Qt-based applications, I get the following error,
followed by a segmentation fault. Which, I believe is due to a bug in
Qt.


qt.qpa.xcb: xcb_shm_create_segment() can't be called for size 17178820624, 
maximumallowed size is 4294967295


This only happen on applications that (try to) show a splash screen,
like fritzing and shortcut. And only happen on my machine that has a 4K
monitor.

Here's what I understand of what happen:

The application tries to show a window for the splash screen. The method
QXcbWindow::create() calls QXcbWindow::propagateSizeHints() which end up
calling xcb_icccm_size_hints_set_base_size with a size of (-2, -2).
We get these values because the window baseSize isn't initialized yet
and HiDPI-scaled.
These hints are then sent to the X server.

Those values are then sent back to the application as some
ConfigureNotify event (I believe) as a pair of uint16_t. This prompts Qt
to try to reallocate an unreasonably large buffer to accomodate the
"resized" window.

Here are the few lines of logs obtained with
QT_LOGGING_RULES='qt.qpa.*=true' right before the warning message that
lead to a crash.

qt.qpa.events: Event | XCB_PROPERTY_NOTIFY(28) | sequence: 402
qt.qpa.events: Event | XCB_PROPERTY_NOTIFY(28) | sequence: 402
qt.qpa.events: Event | XCB_CONFIGURE_NOTIFY(22) | sequence: 402
qt.qpa.xcb: [ QWidgetWindow(0x55751b9cc380, name="FSplashScreenClassWindow") ] 
creating shared memory 17178820624 bytes for QSize(65534, 65534) depth 24 bits 
32
qt.qpa.xcb: xcb_shm_create_segment() can't be called for size 17178820624, 
maximumallowed size is 4294967295


I don't know exactly why this only happen on some very specific
combinations of hardwares and softwares, but google tells me this bug
affects several applications and are always related to 4K monitors.
Could be also related to the window manager. I use fluxbox.

I'm not sure why the window baseSize is uninitialized, but in any case,
setting a negative base_size hint in QXcbWindow::propagateSizeHints()
sounds definitely like a bad idea. Maybe the values should be checked
before they are passed to xcb_icccm_size_hints_set_base_size, as is the
case with other hint values in the same method.

Unfortunately, I'm not well-versed enough in Qt to make an example
program. However, just to check that this is the cause of the bug, I
made a workaround using LD_PRELOAD to replace those negative hint values
with zeros. I attach the source code.

Compile with:
gcc -o preload.so -shared -fPIC preload.c -ldl -Wl,--no-as-needed -lxcb-icccm

Run with:
LD_PRELOAD=./preload.so fritzing


Best regards,
Celelibi


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), 
(500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libqt5gui5 depends on:
ii  fontconfig2.13.1-4.4
ii  libc6 2.34-7
ii  libdrm2   2.4.112-3
ii  libegl1   1.5.0-1
ii  libfontconfig12.13.1-4.4
ii  libfreetype6  2.12.1+dfsg-3
ii  libgbm1   22.2.0~rc3-1
ii  libgcc-s1 12.2.0-1
ii  libgl11.5.0-1
ii  libglib2.0-0  2.73.3-3
ii  libharfbuzz0b 2.7.4-1+b1
ii  libice6   2:1.0.10-1
ii  libinput101.21.0-1
ii  libjpeg62-turbo   1:2.1.2-1
ii  libmd4c0  0.4.8-1
ii  libmtdev1 1.1.6-1
ii  libpng16-16   1.6.37-5
ii  libqt5core5a [qtbase-abi-5-15-4]  5.15.4+dfsg-5
ii  libqt5dbus5   5.15.4+dfsg-5
ii  libqt5network55.15.4+dfsg-5
ii  libsm62:1.2.3-1
ii  libstdc++612.2.0-1
ii  libudev1  251.4-3
ii  libx11-6  2:1.8.1-2
ii  libx11-xcb1   2:1.8.1-2
ii  libxcb-glx0   1.15-1
ii  libxcb-icccm4 0.4.1-1.1
ii  libxcb-image0 0.4.0-2
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.15-1
ii  libxcb-render-util0   0.3.9-1+b1
ii  libxcb-render01.15-1
ii  libxcb-shape0 1.15-1
ii  libxcb-shm0   1.15-1
ii  libxcb-sync1  1.15-1
ii  libxcb-xfixes0

Bug#1019371: fritzing: Forward startup script options to the real binary

[Celelibi]

Package: fritzing
Version: 0.9.6+dfsg-2+b1
Severity: minor

Dear Maintainer,

The command 'fritzing' is a shell script that copies and links a bunch
of files in $HOME/.local/lib.fritzing, and then starts the (copied)
binary.

The actual binary has a few command line options.
But the way the script run it, the options are forgotten and not passed
down to the binary.

The fix should be as simple as changing the last line to:

exec ${LOCAL_FRITZING}/app/Fritzing "$@"


Best regards,
Celelibi


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), 
(500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fritzing depends on:
ii  fritzing-data0.9.6+dfsg-2
ii  fritzing-parts   0.9.6~unreleased-1
ii  libc62.34-7
ii  libgcc-s112.2.0-1
ii  libgit2-1.3  1.3.0+dfsg.1-3
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5gui5   5.15.4+dfsg-5
ii  libqt5network5   5.15.4+dfsg-5
ii  libqt5printsupport5  5.15.4+dfsg-5
ii  libqt5serialport55.15.4-2
ii  libqt5sql5   5.15.4+dfsg-5
ii  libqt5sql5-sqlite5.15.4+dfsg-5
ii  libqt5svg5   5.15.4-2
ii  libqt5widgets5   5.15.4+dfsg-5
ii  libqt5xml5   5.15.4+dfsg-5
ii  libstdc++6   12.2.0-1
ii  zlib1g   1:1.2.11.dfsg-4.1

fritzing recommends no packages.

fritzing suggests no packages.

-- no debconf information

Bug#1007981: cvc4: Consider upgrading to cvc5

[Celelibi]

Source: cvc4
Version: 1.8-2
Severity: normal
Tags: upstream

Dear Maintainers,

It looks like the upstream CVC4 repository[1] is archived. Suggesting it
will no longer be maintained.

Is is, however succeeded by cvc5[2] which improves CVC4 in a number of
ways.

Best regards,
Celelibi

[1] https://github.com/CVC4/CVC4-archived
[2] https://github.com/cvc5/cvc5

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_BAD_PAGE, TAINT_DIE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1001551: xpdf: Argument parsing: -exec with spaces

[Celelibi]

Package: xpdf
Version: 3.04+git20211021-1
Severity: normal

Dear Maintainer,

I love the ability to control xpdf from another program. Makes it easy
to integrate into my workflow.

However, it looks like xpdf doesn't parse correctly the -exec argument
value when it includes spaces.

For instance, run:
xpdf -remote myxpdf somedocument.pdf

Then run:
xpdf -remote myxpdf -exec 'run(ls)'

This works, the first xpdf command will run 'ls'. However the following
command fails:
xpdf -remote myxpdf -exec 'run(ls -l)'

And it fails at the client side, showing a brief command line help. Not
at the remote server side. Therefore suggesting it's a command line
parsing issue.

Best regards,
Celelibi

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xpdf depends on:
ii  libc6  2.32-4
ii  libgcc-s1  11.2.0-12
ii  libpaper1  1.1.28+b1
ii  libpoppler102  20.09.0-3.1
ii  libstdc++6 11.2.0-12
ii  libx11-6   2:1.7.2-2+b1
ii  libxm4 2.3.8-3
ii  libxt6 1:1.2.0-1

Versions of packages xpdf recommends:
pn  cups-bsd
ii  gsfonts-x11 0.28
ii  poppler-data0.4.11-1
ii  poppler-utils   20.09.0-3.1
ii  sensible-utils  0.0.17

xpdf suggests no packages.

-- no debconf information

Bug#922876: lua5.3: Please provide a 'lua' metapackage package that depends on the latest version

[Celelibi]

Control: reopen -1
Control: thx

Thanks for the attention you gave to this report.

> There is a virtual lua package that does the trick.

Unfortunately, no. It doesn't do the trick. Virtual packages aren't
installable.


# apt install lua
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package lua is a virtual package provided by:
  lua50 5.0.3-8.1
  lua5.4 5.4.3-1
  lua5.3 5.3.3-1.1+b1
  lua5.2 5.2.4-1.1+b3
  lua5.1 5.1.5-8.1+b3
You should explicitly select one to install.

E: Package 'lua' has no installation candidate



See packages like python3 or gcc for examples of what I mean.
They have dependencies to (for instance) python3.9 and gcc-10.

Best regards,
Celelibi

Bug#944542: aws-shell: prompt_toolkit 3.x support

[Celelibi]

control: retitle -1 aws-shell: prompt_toolkit 3.x support
control: thanks

aws-shell now pulls the version 3 of python3-primpt-toolkit.
Here is the backtrace when I try to run it:

Traceback (most recent call last):
  File "/usr/bin/aws-shell", line 11, in 
load_entry_point('aws-shell==0.2.1', 'console_scripts', 'aws-shell')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 474, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2846, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/awsshell/__init__.py", line 9, in 

from awsshell import app
  File "/usr/lib/python3/dist-packages/awsshell/app.py", line 13, in 
from prompt_toolkit.shortcuts import create_eventloop
ImportError: cannot import name 'create_eventloop' from 
'prompt_toolkit.shortcuts' 
(/usr/lib/python3/dist-packages/prompt_toolkit/shortcuts/__init__.py)



Best regards,
Celelibi

Bug#987955: google-android-build-tools-installer: Missing dependency to libc++1:i386

[Celelibi]

Package: google-android-build-tools-installer
Version: 23.0.3+r1
Severity: important

Dear Maintainer,

The tool aapt installed by this package requires the shared library
libc++.so. It should probably be maked as a dependency.

Moreover, the installed aapt binary is a 32 bits ELF. Therefore, it
requires a 32 bits libc++.so library. Are cross-architecture
dependencies possible?

Best regards,
Celelibi

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages google-android-build-tools-installer depends on:
ii  build-essential12.9
ii  ca-certificates20210119
ii  debconf [debconf-2.0]  1.5.75
ii  dpkg-dev   1.20.9
ii  libstdc++6 10.2.1-6
ii  make   4.3-4.1
ii  po-debconf 1.0.21+nmu1
ii  unzip  6.0-26
ii  wget   1.21-1+b1
ii  zlib1g 1:1.2.11.dfsg-2

google-android-build-tools-installer recommends no packages.

google-android-build-tools-installer suggests no packages.

-- debconf information:
* google-android-installers/mirror: https://dl.google.com

Bug#982661: mame: Crash on startup

[Celelibi]

Hello,

After some debugging, here are some informations:
- I use the r300 mesa driver.
- Hardware accelerated programs like glxgears tend to work, but crash
  when they exit.
- They crash with the same backtrace.
- The driver r300 doesn't implement the function set_shader_buffers.
- Setting LIBGL_DEBUG=verbose isn't very informative, see below [1].
- Actually, in the function cso_destroy_context [2], we can see it would
  be expected that the value of maxssbo to be 0. Instead I get 16.
- This bug has been fixed upstream [3].
- The fix has been backported to the release 21.0.0.

So I guess this bug report should be reassigned to the package
libgl1-mesa-dri, retitled accordingly and marked as fixed upstream. And
probably be closed as soon as the release 21.0.0 reach debian sid.


Best regards,
Celelibi



[1]
libGL: using driver radeon for 5
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: pci id for fd 5: 1002:791f, driver r300
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/r300_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: Using DRI2 for screen 0


[2]
int maxssbo = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_BUFFERS);
...
if (maxssbo > 0) {
   ctx->pipe->set_shader_buffers(ctx->pipe, sh, 0, maxssbo, ssbos, 0);
}

[3] 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/58e43594fc457eaaf1b1e01e48948959a82080bc

Bug#982661: mame: Crash on startup

[Celelibi]

It still crashes, indeed.

Best regards,
Celelibi

Le Sun, Mar 07, 2021 at 05:00:07PM +0100, Bernhard Übelacker a écrit :
> Hello Celelibi,
> does this happen with current version
> in testing 0.228+dfsg.1-1, too?
> 
> Kind regards,
> Bernhard

Bug#982661: mame: Crash on startup

[Celelibi]

Package: mame
Version: 0.227+dfsg.1-1
Severity: important

Dear Maintainer,

After an upgrade, mame started crashing on startup. I think it's
unlikely that it's mame's fault, but I'll let you decide to forward to
bug to libsdl2 or something else of needed.

Here is a run in gdb with a full stack trace.

--
$ gdb mame
Reading symbols from mame...
Reading symbols from 
/usr/lib/debug/.build-id/6b/74368acfb3eea244cebfc8fb10056378166e6c.debug...
(gdb) directory code/debsrc/mesa-20.3.4/debian
Source directories searched: 
/home/celelibi/code/debsrc/mesa-20.3.4/debian:$cdir:$cwd
(gdb) run
Starting program: /usr/games/mame
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Error opening translation file English
[Detaching after fork from child process 698623]
[New Thread 0x7fffea0b8700 (LWP 698740)]
[New Thread 0x7fffe9762700 (LWP 698741)]
[New Thread 0x7fffe8f61700 (LWP 698742)]
[New Thread 0x7fffe3fff700 (LWP 698743)]
[New Thread 0x7fffe37fe700 (LWP 698744)]

Thread 1 "mame" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x70edb23f in cso_destroy_context (ctx=0x6b27a9e0) at 
../src/gallium/auxiliary/cso_cache/cso_context.c:419
#2  0x709f7704 in st_destroy_context_priv (st=st@entry=0x6b279020, 
destroy_pipe=destroy_pipe@entry=true) at 
../src/mesa/state_tracker/st_context.c:471
#3  0x709f8a94 in st_destroy_context (st=0x6b279020) at 
../src/mesa/state_tracker/st_context.c:1150
#4  0x709da95e in dri_destroy_context (cPriv=) at 
../src/gallium/frontends/dri/dri_context.c:247
#5  0x70ed9903 in driDestroyContext (pcp=0x6b06aa00) at 
../src/mesa/drivers/dri/common/dri_util.c:533
#6  0x722515af in dri2_destroy_context (context=0x6b06a870) at 
../src/glx/dri2_glx.c:123
#7  0x7223fe49 in glXDestroyContext (ctx=0x6b06a870, 
dpy=0x6afe9bf0) at ../src/glx/glxcmds.c:510
#8  glXDestroyContext (dpy=0x6afe9bf0, ctx=0x6b06a870) at 
../src/glx/glxcmds.c:491
#9  0x77ed56ed in X11_GL_InitExtensions (_this=0x6afeb890) at 
./src/video/x11/SDL_x11opengl.c:464
#10 X11_GL_LoadLibrary (_this=0x6afeb890, path=) at 
./src/video/x11/SDL_x11opengl.c:238
#11 0x77eaf116 in SDL_GL_LoadLibrary_REAL (path=path@entry=0x0) at 
./src/video/SDL_video.c:3012
#12 0x77eb1771 in SDL_CreateWindow_REAL 
(title=title@entry=0x77f246b5 "OpenGL test", x=x@entry=-32, y=y@entry=-32, 
w=w@entry=32, h=h@entry=32, flags=flags@entry=10) at 
./src/video/SDL_video.c:1489
#13 0x77eb1fff in ShouldUseTextureFramebuffer () at 
./src/video/SDL_video.c:225
#14 SDL_VideoInit_REAL (driver_name=, driver_name@entry=0x0) at 
./src/video/SDL_video.c:545
#15 0x77e0af47 in SDL_InitSubSystem_REAL (flags=16416) at 
./src/SDL.c:216
#16 0x5ee925c8 in sdl_osd_interface::init(running_machine&) ()
#17 0x63894f79 in running_machine::start() ()
#18 0x63896c29 in running_machine::run(bool) ()
#19 0x5ef8cf85 in mame_machine_manager::execute() ()
#20 0x5f037d36 in cli_frontend::start_execution(mame_machine_manager*, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > > const&) ()
#21 0x5f03800e in 
cli_frontend::execute(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > >&) ()
#22 0x5ef8a876 in emulator_info::start_frontend(emu_options&, 
osd_interface&, std::vector, std::allocator >, 
std::allocator, 
std::allocator > > >&) ()
#23 0x5a221fcb in main ()
(gdb) frame 1
#1  0x70edb23f in cso_destroy_context (ctx=0x6b27a9e0) at 
../src/gallium/auxiliary/cso_cache/cso_context.c:419
419ctx->pipe->set_shader_buffers(ctx->pipe, sh, 0, maxssbo, 
ssbos, 0);
(gdb) p ctx->pipe->set_shader_buffers
$1 = (void (*)(struct pipe_context *, enum pipe_shader_type, unsigned int, 
unsigned int, const struct pipe_shader_buffer *, unsigned int)) 0x0
--

I doubt the crash has anything to do with the error about the English
translation, since it crashes during the initialization of the video
subsystem.

Best regards,
Celelibi



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mame depends on:
ii  libc6  2.31-9
ii  libexpat1  2.2.10-1
ii  libflac8   1.

Bug#982553: python3-aalib: ABI mismatch on amd64

[Celelibi]

Package: python3-aalib
Version: 0.3.2-4
Severity: normal

Dear Maintainer,

It looks like there's an ABI mismatch between the structure layout
declared in the python code and the actual layout.

It causes python to allocate less memory than needed by the C library.
On rare occasions, the uninitialized field gets a non-zero value, which
produce weird behaviors.

Specifically, the struct fields of aa_hardware_params and
aa_render_params are only aligned on 4 bytes on i386 when compiled with
gcc. Not on x64 or any other architecture as far as I can tell.

When reading the beginning of aalib.h we can see:

/* The -malign-double switch changes binarry compatibility with structures
   containing floating point values.  To avoid this, set alignment manually
   to old value.  */

#ifdef __GNUC__
#ifdef __i386__
#define __AA_ALIGN __attribute__ ((__aligned__ (4)))
#define __AA_NOALIGN __attribute__ ((__packed__))
#endif
#endif


Which shows explicitely that the struct fields are only aligned or
packed on i386. Given the specificity of the condition and the comment
above, my guess would be that this was made only to prevent an ABI
breakage when upgrading gcc, and not a general definition.

Therefore I think that the _pack_ = 4 attribute when declaring the
structures is too strict.

class HardwareSettings(Structure):
_pack_ = 4
_fields_ = [
# ...
]


Although I have no clue how to detect it, this should probably be set
only for the 32 bits builds on intel-compatible platforms (only when
__i386__ is set). Note that 32 bits systems can be installed on 64 bits
hardware, and 32 bits builds of python can be installed in 64 bits
debian systems. So it should really be the ELFCLASS of the library that
should be tested, neither the architecture of the hardware nor the
debian arch.


On the other hand, maybe an easier fix would be to have a more
consistent ABI on the aalib side? Although this would mean bumping the
ABI version and possibly breaking many packaged, this might be the best
long-term solution. If you think so, feel free to reassign this bug
report as needed.



Best regards,
Celelibi


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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-aalib depends on:
ii  libaa1   1.4p5-48
ii  python3  3.9.1-1

python3-aalib recommends no packages.

Versions of packages python3-aalib suggests:
ii  python3-pil  8.1.0-1

-- no debconf information

Bug#982147: mgba: Please provide a libmgba-dev package

[Celelibi]

Le Sun, Feb 07, 2021 at 02:50:28PM -0800, Ryan Tandy a écrit :
> On Sun, Feb 07, 2021 at 10:05:38PM +0100, Celelibi wrote:
> > The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I
> > don't think it would be a good candidate for inclusion in Debian as I
> > intend it to be a quick-and-dirty program for my specific needs.
> 
> OK. Sounds fun. :)
> 
> > I have no idea of an ABI compatibility policy. I'm not sure there's one
> > right now.
> 
> OK.
> 
> > However, the CMakeLists.txt already contains everything needed to
> > install headers. So I guess there's an intent toward this usage even if
> > the support (especially regarding ABI stability) isn't well thought out.
> 
> Sure. I didn't mean to suggest that the library isn't meant to be used. In
> fact, It looks like upstream's own .deb packages also include mgba-dev as
> well as libmgba. However, for publishing it in Debian, it needs to meet the
> requirements set by Debian policy for shared libraries. (And I'm not even
> saying that it doesn't, only that I don't know whether it does or not.)

I opened a github issue asking for an official stance.
https://github.com/mgba-emu/mgba/issues/2042

In the mean time, I found out how was the SONAME generated. It looks
like the ABI version is managed explicitely and used to produce a SONAME.
https://github.com/mgba-emu/mgba/blob/32a8a47d/CMakeLists.txt#L880
https://github.com/mgba-emu/mgba/blob/32a8a47d/version.cmake#L7

So I would expect a positive outcome soon.

Regards,
Celelibi

Bug#982147: mgba: Please provide a libmgba-dev package

[Celelibi]

Le Sat, Feb 06, 2021 at 01:41:04PM -0800, Ryan Tandy a écrit :
> What is the software that would like to use this? Is it (or would it
> eventually be) in Debian?

The program I'm writing would be an IRC bot a-la twitch-plays-pokemon. I
don't think it would be a good candidate for inclusion in Debian as I
intend it to be a quick-and-dirty program for my specific needs.


> What is libmgba's ABI policy? Currently we use libmgba as a "private"
> library; only the frontends built from the same source link it, with tight
> version constraints. I guess shipping a -dev package would require making
> the library package public, and versioning it appropriately. It looks like
> libmgba's SONAME is derived from its version (i.e.  "libmgba.so.0.8") and
> does not reflect libtool-style versioning? Does mgba's author commit to ABI
> compatibility within the scope of a release branch?
> 
> (If it is attached to the release version that way, I'd have thought it's
> more conventional to name it e.g. "libmgba-0.8.so.0", but that's upstream's
> decision of course...)
> 
> In short, it's easy to ship some headers and a .so symlink, but I'm somewhat
> more hesitant about making libmgba into a public library, when it's not
> obvious to me that it's meant to be used that way, so I'd appreciate any
> links to where I can read about upstream's intent.

I have no idea of an ABI compatibility policy. I'm not sure there's one
right now.

However, the CMakeLists.txt already contains everything needed to
install headers. So I guess there's an intent toward this usage even if
the support (especially regarding ABI stability) isn't well thought out.
All I can say for sure right now is that the ABI will likely break with
version 0.9 because of a new field in the struct Table.

What exactly would be needed from the author of libmgba to make it
suitable as a public library? Would it be enough if they set a rule
saying that the minor version would be bumped at least on every ABI
break?

Best regards,
Celelibi

Bug#982147: mgba: Please provide a libmgba-dev package

[Celelibi]

Source: mgba
Version: 0.8.4+dfsg-1
Severity: normal

Dear Maintainer,

The project mgba has been architectured with a libmgba handling the
emulation and frontends that use it. This also allow for other programs
to use this library to embed an emulator.

But doing so would require having at least the same version of the C
headers and the generated src/core/flags.h. Without the headers, any
update of libmgba would break existing programs. Even worse, without
flags.h we can only try to guess which options were defined during the
compilation of the libmgba.so to get an ABI compatiblity.

As I understand, the build process of the upstream code is already ready
for this. The files just need to be packaged and installed.

I guess that in addition to the headers, the static version of the
library could also be compiled and packaged, although I personnally
would have no use for it.

Best regards,
Celelibi

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#980435: osdsh: Silent SIGSEGV at startup

[Celelibi]

I am pretty knowledgable in C and dynamic linking.
In theory, I would also be very happy to contribute to maintaining this
package. However, time is an ongoing issue and I would need to learn to
make packages for Debian.

I noticed how old was this patch. It doesn't feel very healthy to keep
some non-bug-fixing paches for so long in debian. (But I saw on your
blog you already have had this kind of discussion.) And the upstream
project seems dead.

The last commits dates back June or July 2002 and neither modules have
much history. It looks like this project was written once and fogotten.

Have you tried contacting the upstream author?
It seems like the best course of action would be to adopte the upstream
project, don't you think?

This lack of upstream activity also means that the recent break was
introduced by the last NMU by Andrej Shadura. I CC him too.
Likely the patch 14-allocate-mixerdevice-only-once.patch.

In fact, reading the code, I think the lines where the crash happen are
just not needed anymore.

Best regards,
Celelibi

Le Tue, Jan 19, 2021 at 09:35:03AM +0100, Joachim Breitner a écrit :
> Control: tag -1 + help
> 
> thanks for the report! This patch is 13 years old, oh wey. I might need
> help from someone who nows C, X11 and dynamic linking better than I do.
> 
> Also happy to pass on maintainership of this package to someone else, I
> am not using it myself anymore.
> 
> Cheers,
> Joachim 
> 
> Am Dienstag, den 19.01.2021, 06:40 +0100 schrieb Celelibi:
> > Package: osdsh
> > Version: 0.7.0-10.4
> > Severity: grave
> > Justification: renders package unusable
> > 
> > Dear Maintainer,
> > 
> > Nowadays, osdsh crashes without a message.
> > The cause I identified is that it looks for a symbol "mixerdevice" in
> > the shared library libosdshmixer.so which doesn't exist.
> > Since the return of dlsym isn't checked, it dereferences a NULL pointer.
> > 
> > In the function load_plugin in src/osdsh/controlsh.c:
> > mod_mixerdev = dlsym(module, "mixerdevice");
> > *mod_mixerdev = mixerdevice;
> > 
> > These lines seems to have been added by the debian patch
> > 06-fix-m-option.patch.
> > 
> > I guess this patch could be reworked to work with the new version.
> > 
> > Best regards,
> > Celelibi
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 5.10.0-1-amd64 (SMP w/2 CPU threads)
> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages osdsh depends on:
> > ii  libc6 2.31-9
> > ii  libxosd2  2.2.14-2.1+b1
> > ii  tk8.6.10
> > 
> > osdsh recommends no packages.
> > 
> > osdsh suggests no packages.
> > 
> > -- no debconf information
> > 
> -- 
> Joachim “nomeata” Breitner • nome...@debian.org • https://j.oach.im/
>   

Bug#980435: osdsh: Silent SIGSEGV at startup

[Celelibi]

Package: osdsh
Version: 0.7.0-10.4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Nowadays, osdsh crashes without a message.
The cause I identified is that it looks for a symbol "mixerdevice" in
the shared library libosdshmixer.so which doesn't exist.
Since the return of dlsym isn't checked, it dereferences a NULL pointer.

In the function load_plugin in src/osdsh/controlsh.c:
mod_mixerdev = dlsym(module, "mixerdevice");
*mod_mixerdev = mixerdevice;

These lines seems to have been added by the debian patch
06-fix-m-option.patch.

I guess this patch could be reworked to work with the new version.

Best regards,
Celelibi

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

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

Versions of packages osdsh depends on:
ii  libc6 2.31-9
ii  libxosd2  2.2.14-2.1+b1
ii  tk8.6.10

osdsh recommends no packages.

osdsh suggests no packages.

-- no debconf information

Bug#978654: python3-cypari2: Depends on cysignals

[Celelibi]

Package: python3-cypari2
Version: 2.1.2-1+b1
Severity: important

Dear Maintainer,

The module cypari2 seems to be impossible to import without the module
cysignals.

Here's the traceback:

>>> import cypari2
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/cypari2/__init__.py", line 1, in 
from .pari_instance import Pari
  File "cypari2/pari_instance.pyx", line 1, in init cypari2.pari_instance
  File "cypari2/gen.pyx", line 1, in init cypari2.gen
  File "cypari2/stack.pyx", line 1, in init cypari2.stack
ModuleNotFoundError: No module named 'cysignals'


Installing python3-cysignals-bare or python3-cysignals-pari fixes it.
Therefore, I would suggest adding a dependency to
'python3-cysignal-bare | python3-cysignals-pari'.

Best regards,
Celelibi


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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-cypari2 depends on:
ii  libc6 2.31-6
ii  libpari-gmp-tls7  2.13.0-2
ii  python3   3.9.0-4

python3-cypari2 recommends no packages.

python3-cypari2 suggests no packages.

-- no debconf information

Bug#569049: Fixed upstream

[Celelibi]

My bad, the latest commit didn't fix this issue. It was actually fixed
back in 2014, and this fix is available in the the release 1.4.

Here is the link to the exact commit that fixed it.
https://github.com/raas/mbw/commit/6346daa765f85d47caa39685fb452701d82446d5

Best regards,
Celelibi

Bug#569049: mbw: Memory bandwith test inverts DUMB and MEMCPY tests. Dumb copy appears faster than memcpy

[Celelibi]

For what it's worth. This bug has just been fixed upstream.
https://github.com/raas/mbw
10 years after was reported here. ^^

Let's just hope that the maintainer of this package is still around and
will eventally upgrade.

Best regards,
Celelibi

Bug#961062: libmkl-rt: libmkl_rt.so should dlopen libiomp5.so with flag RTLD_GLOBAL

[Celelibi]

Package: libmkl-rt
Version: 2020.1.217-2
Severity: normal

Dear Maintainer,

The library libmkl_rt.so seems to load libiomp5.so dynamically with a
call to dlopen that probably looks more-or-less like this:

dlopen("/usr/lib/x86_64-linux-gnu/libiomp5.so", RTLD_LAZY|RTLD_GLOBAL);

The use of the flag RTLD_GLOBAL place this library in the global scope
for the run-time symbol resolution.

This libiomp5 is provided by llvm and appear to try to be ABI-compatible
with the libgomp provided by gcc by defining the same symbols.

This may cause an issue when another library was linked against a
different version of libgomp. Some symbols might end up being
dynamically linked to libiomp5 and others to libgomp.

This happens in practice right now since for some OpenMP directives,
gcc-9 now generate calls to GOMP_loop_nonmonotonic_dynamic_next that
were calls to GOMP_loop_dynamic_next with gcc-8. Therefore, a library
compiled with gcc-9 and linked against libgomp would, at run time, have
its older symbols bound to libiomp5 while the newer would be bound to
the newer version of libgomp.

I guess the right thing to do fix this would be to not pollute the
global scope and always load libiomp5.so without the flag RTLD_GLOBAL.


Best regards,
Celelibi


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

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

Versions of packages libmkl-rt depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libatlas3-base [liblapack.so.3]3.10.3-9
ii  libblas3 [libblas.so.3]3.9.0-2
ii  libc6  2.30-4
ii  libgcc-5-dev   5.5.0-12
ii  libgcc-6-dev   6.5.0-1
ii  libgcc-7-dev   7.5.0-5
ii  libgcc-8-dev   8.4.0-3
ii  liblapack3 [liblapack.so.3]3.9.0-2
ii  libmkl-locale  2020.1.217-2
ii  libmkl-meta-computational  2020.1.217-2
ii  libmkl-meta-interface  2020.1.217-2
ii  libmkl-meta-threading  2020.1.217-2
ii  libomp-7-dev   1:7.0.1-12
ii  libopenblas0-pthread [liblapack.so.3]  0.3.9+ds-1

libmkl-rt recommends no packages.

libmkl-rt suggests no packages.

-- debconf information:
* libmkl-rt/use-as-default-blas-lapack: true
* libmkl-rt/exact-so-3-selections: libblas.so.3, liblapack.so.3, 
libblas64.so.3, liblapack64.so.3,
  libmkl-rt/title:

Bug#958476: python3-gevent: gevent 1.4 not compatible with python 3.8

[Celelibi]

Package: python3-gevent
Version: 1.4.0-1.2
Severity: important

Dear Maintainer,

I recently came across this bug:
https://github.com/gevent/gevent/issues/1491

In short the DNS resolver fail with a TypeError when the name cannot be
resolved.

And this comment say that gevent 1.4 is not compatible with python3.8.
https://github.com/gevent/gevent/issues/1491#issuecomment-564217771

But since python3-gevent is marked as depending on python >= 3.8~, I
don't know what it should be compatible with. I guess more tests are
needed.

However, the version 1.5.0 should include the fix. It has been released
about 2 weeks ago. Therefore I think the best way to fix this bug would
be to hasten the upgrade of this package.

Best regards
Celelibi

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

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

Versions of packages python3-gevent depends on:
ii  libc6 2.30-4
ii  python3   3.8.2-3
ii  python3-greenlet  0.4.15-4.2

python3-gevent recommends no packages.

Versions of packages python3-gevent suggests:
pn  python-gevent-doc   
pn  python3-gevent-dbg  
pn  python3-openssl 

-- no debconf information

Bug#958335: python3-caffe-cuda: No longer installable, please upgrade

[Celelibi]

Package: python3-caffe-cuda
Version: 1.0.0+git20180821.99bd997-2+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

python3-caffe-cuda is uninstallable because of its dependencies. Both
direct and indirect.

It depends on python3 << 3.8. While Python 3.8 is now the default
version.

There seem to be similar issues with the other dependencies.

Best regards,
Celelibi


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

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

Versions of packages python3-caffe-cuda depends on:
ii  cython3 0.29.14-1
ii  libboost-python1.67.0   1.67.0-17
ii  libboost-system1.67.0   1.67.0-17
ii  libc6   2.30-4
pn  libcaffe-cuda1  
ii  libgcc-s1 [libgcc1] 10-20200411-1
ii  libgcc1 1:10-20200411-1
ii  libgoogle-glog0v5   0.4.0-1
pn  libprotobuf17   
pn  libpython3.7
ii  libstdc++6  10-20200411-1
ii  python3 3.8.2-3
ii  python3-dateutil2.7.3-3
ii  python3-gflags  1.5.1-7
ii  python3-h5py2.10.0-2+b1
ii  python3-ipython 7.13.0-1
pn  python3-leveldb 
ii  python3-matplotlib  3.1.2-2
ii  python3-networkx2.4-3
ii  python3-nose1.3.7-5
ii  python3-numpy [python3-numpy-abi9]  1:1.17.4-5
ii  python3-pandas  0.25.3+dfsg-9
ii  python3-pil 6.2.1-2+b1
ii  python3-protobuf3.11.4-4
ii  python3-scipy   1.3.3-3+b1
ii  python3-six 1.14.0-2
ii  python3-skimage 0.16.2-2
ii  python3-yaml5.3.1-1+b1

python3-caffe-cuda recommends no packages.

python3-caffe-cuda suggests no packages.

Bug#954895: cryptominisat: Uninstallable because of outdated dependencies

[Celelibi]

Source: cryptominisat
Version: 5.6.4+dfsg.1-1+b3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Although the library and development files can be installed just fine,
the command line tool cannot.

The package cryptominisat depends on libboost-program-options1.62.0
which doesn't exist anymore.

Would it be possible to provide a package compiled against a newer
version?

Best regards,
Celelibi

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

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

Bug#952901: shotcut: Segmentation fault on 4K monitor

[Celelibi]

Package: shotcut
Version: 20.02.17-2
Severity: important

Dear Maintainer,

When I try to run shotcut on a 4K monitor I get the following logs:

$ LANG=C shotcut
[Info   ]  Starting Shotcut version 20.02.21 
[Info   ]  Linux version 
[Info   ]  number of logical cores = 8 
[Info   ]  locale = QLocale(C, Default, Default) 
[Info   ]  install dir = "/usr/bin" 
[Info   ]  device pixel ratio = 2 
[Debug  ]  language "C" 
[Debug  ]  deinterlacer "onefield" 
[Debug  ]  external monitor "" 
[Debug  ]  GPU processing true 
[Debug  ]  interpolation "bilinear" 
[Debug  ]  video mode "" 
[Debug  ]  realtime true 
[Debug  ]  audio channels 2 
No appenders associated with category qt.qpa.xcb
[Warning] <> xcb_shm_create_segment() can't be called for size 17178820624, 
maximumallowed size is 4294967295
zsh: segmentation fault  LANG=C shotcut


And here's an extract of a more verbose log:

$ QT_LOGGING_RULES='*.debug=true' shotcut
...
[Debug  ] <> [ QWidgetWindow(0x55c4be7b5c20, name="QSplashScreenClassWindow") ] 
creating shared memory 17178820624 bytes for QSize(65534, 65534) depth 32 bits 
32
No appenders associated with category qt.qpa.xcb
[Warning] <> xcb_shm_create_segment() can't be called for size 17178820624, 
maximumallowed size is 4294967295
No appenders associated with category qt.scaling
[Debug  ] <> QBackingStore::beginPaint new backingstore for 
QWidgetWindow(0x55c4be7b5c20, name="QSplashScreenClassWindow")
No appenders associated with category qt.scaling
[Debug  ] <>   source size QSize(65534, 65534) dpr 1
No appenders associated with category qt.scaling
[Debug  ] <>   destination size QSize(65534, 65534) dpr 2
...


And finally is an extract of the output of xrandr:

$ xrandr -q | head
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
HDMI-0 disconnected primary (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
eDP-1-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 
346mm x 194mm
   3840x2160 60.00*+  59.9848.0259.97  
   3200x1800 59.9659.94  
   2880x1620 59.9659.97  
   2560x1600 59.9959.97  
   2560x1440 59.9959.9959.9659.95  



It looks like Qt tries to allocate some memory for the splash screen,
but with a size that's so large it doesn't really make sens.

Note that the requested amount of memory is exactly 65534*65534*4. And
this size is exactly twice the maximum screen size: 32767*32767. The
screen size is not an exact power of two, so this would be an odd
coincidence.

I don't know if the bug is rather in shotcut or in Qt. Or maybe in the
way they interact. Feel free to reassign this bug report if needs be.


Best regards,
Celelibi

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

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

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200222-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-7
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200222-1
ii  melt   6.20.0-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#951914: primus: Unusable with newest glx driver

[Celelibi]

Package: primus
Version: 0~20150328-9
Severity: grave
Justification: renders package unusable

Dear Maintainer,

As stated in bug #888020 primus is currently not compatible with the
GLVND variants of the GLX drivers. As a result, primus was tagged as
breaking libgl1-nvidia-glvnd-glx.

As I understand, nvidia is deprecating the non-GLVND variants [1] and
version 430 is the last of this kind. And as far as I know, in debian,
the latest non-GLVND version available is the 418.74-1 and is in the
stable release. The only other version available in debian testing and
sid is currently the GLVND variant 440.59-1.

Meaning that primus is currently completely unusable with debian testing
and sid.

I would therefore suggest to reevaluate the "breaks:" tags and find a
way to make primus support GLVND. I mean. I think that's the only way.


Best regards,
Celelibi


[1] 
https://devtalk.nvidia.com/default/topic/1032650/linux/unix-graphics-feature-deprecation-schedule/


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

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

Versions of packages primus depends on:
ii  bumblebee 3.2.1-20
ii  primus-libs   0~20150328-9
ii  socat 1.7.3.3-2
ii  xserver-xorg-core 2:1.20.7-3
ii  xserver-xorg-video-intel  2:2.99.917+git20190815-1

Versions of packages primus recommends:
pn  primus-libs-ia32  

Versions of packages primus suggests:
pn  nvidia-driver-libs-nonglvnd | nvidia-legacy-390xx-driver-libs-nongl  

-- no debconf information

Bug#951727: qmelt: command not found

[Celelibi]

Package: shotcut
Version: 20.02.17-1
Followup-For: Bug #951727

The error message is pretty simple (and is mostly the subject of this
bug report).

When I try to export a video, the export job fails immediately and its log
(accessible via right-click on the job) says verbatim:

/usr/bin/nice: '/usr/bin/qmelt': No such file or directory
Failed with exit code 127


However, I think I found a workaround.
As I understand, qmelt is supposed to be provided by mltframework. It
looks like it's actually part of the melt package, with the name 'melt',
instead of 'qmelt'.

Therefore, an easy workaround that works for me is to install melt and
make a symlink from qmelt to melt.

I'm not sure whether the package melt is actually supposed to provide a
binary named qmelt. Anyway I guess a fix could be to add a dependency to
melt and add a postinst script that runs:
ln -s /usr/bin/melt /usr/bin/qmelt

Best regards,
Celelibi

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

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

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200211-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-6
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200211-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#951727: qmelt: command not found

[Celelibi]

Package: shotcut
Version: 20.02.17-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

shotcut uses the program qmelt to export the videos. However, unless I'm
mistaken, this program is nowhere to be found in debian.

This has already been asked on the forum of shotcut and been discarded
as a packaging issue.
https://forum.shotcut.org/t/shotcut-export-not-working-usr-bin-nice-usr-bin-qmelt-not-found/8043


I tagged this bug as grave since the inability to export a video would
make the whole package pretty useless for most people.

It looks like this bug was already reported back in 2016 for a
non-official debian version.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818114

If anyone has already managed to use this package, I wonder where does
their qmelt program come from.

Best regards,
Celelibi


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200211-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-6
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200211-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#951677: shotcut: Should depend (or recommend) frei0r-plugins

[Celelibi]

Package: shotcut
Version: 20.02.17-1
Severity: important

Dear Maintainer,

When adding a video track in the timeline, a transition is automatically
added. It uses either the transition 'movit.overlay' or
'frei0r.cairoblend'.

This is pretty explicit in the code at:
src/models/multitrackmodel.cpp:2625
Mlt::Transition composite(MLT.profile(), Settings.playerGPU()? "movit.overlay" 
: "frei0r.cairoblend");

Without it, adding the first video track makes the application segfault.
Therefore, I think the easiest fix is to have the shotcut package
depend on frei0r-plugins.

Best regards,
Celelibi


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200211-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-6
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200211-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#950601: lsof: Unreadable manpage

[Celelibi]

Package: lsof
Version: 4.93.2+dfsg-1
Severity: normal

Dear Maintainer,

Here's the output of man when trying to read it.

$ man lsof
man: can't open /usr/share/man/./version: No such file or directory
No manual entry for lsof

I think some script didn't run properly to format the version number at
the begining of the man page.

Best regards,
Celelibi

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

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

Versions of packages lsof depends on:
ii  libc62.29-9
ii  libselinux1  3.0-1

lsof recommends no packages.

Versions of packages lsof suggests:
ii  perl  5.30.0-9

-- no debconf information

Bug#925190: udev: Random execution order of RUN commands

[Celelibi]

On Thu, Mar 21, 2019 at 05:53:52PM +0100, Michael Biebl wrote:
> Am 21.03.19 um 03:58 schrieb Celelibi:
> > It looks like it's actually already fixed upstream.
> > https://github.com/systemd/systemd/issues/11368
> > Fixed by the commit:
> > https://github.com/systemd/systemd/commit/39a15c8a8dad26deda140867f03e44a535b7bd8d
> 
> This sounds like something that should be fixed for buster.
> 
> >> Versions of packages udev is related to:
> >> ii  systemd  241-1
> > 
> > By looking at the debian source, it looks like it's also fixed in 242-2.
> > I'll test it when I can, but I think it should work.
> > 
> 
> I guess you mean 241-2, as there is no 242-2 (yet).
> 241-2 does not contain that upstream fix.

I thought it was. But now, I think I may have confused my terminals
while checking 3 versions in parallel.
It indeed doesn't seem to be fixed yet in 241-2.

> 
> Would be great if you test a package with this fix applied and confirm
> the fix.

I applied the commit 39a15c8a8dad26deda140867f03e44a535b7bd8d on top of
the debian source 241-2. As far as I can tell, it seems to work.

I join the patch as generated from:
$ git format-patch -1 39a15c8a8d

Note that some hunks apply with an offset. But nontheless, it applies
and work.

Best regards,
Celelibi
>From 39a15c8a8dad26deda140867f03e44a535b7bd8d Mon Sep 17 00:00:00 2001
From: Yu Watanabe 
Date: Tue, 5 Mar 2019 04:01:34 +0900
Subject: [PATCH] udev: run programs in the specified order

This fixes bugs introduced by 29448498c724da7ade1b5efb20d7472c1b128d2c
and d838e14515c82b05a07f2bf393cce057b45b2b53.

Previously, RUN and SECLABEL keys are stored in udev_list with its unique
flag is false. If the flag is false, then udev_list is just a linked
list and new entries are always added in the last.
So, we should use OrderedHashmap instead of Hashmap.

Fixes #11368.
---
 src/udev/udev-event.c   |  6 +++---
 src/udev/udev-node.c|  6 +++---
 src/udev/udev-node.h|  2 +-
 src/udev/udev-rules.c   | 12 ++--
 src/udev/udev.h |  4 ++--
 src/udev/udevadm-test.c |  2 +-
 6 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c
index 6f90516ff6..9ede330c27 100644
--- a/src/udev/udev-event.c
+++ b/src/udev/udev-event.c
@@ -71,8 +71,8 @@ UdevEvent *udev_event_free(UdevEvent *event) {
 sd_device_unref(event->dev);
 sd_device_unref(event->dev_db_clone);
 sd_netlink_unref(event->rtnl);
-hashmap_free_free_key(event->run_list);
-hashmap_free_free_free(event->seclabel_list);
+ordered_hashmap_free_free_key(event->run_list);
+ordered_hashmap_free_free_free(event->seclabel_list);
 free(event->program_result);
 free(event->name);
 
@@ -891,7 +891,7 @@ void udev_event_execute_run(UdevEvent *event, usec_t timeout_usec) {
 void *val;
 Iterator i;
 
-HASHMAP_FOREACH_KEY(val, cmd, event->run_list, i) {
+ORDERED_HASHMAP_FOREACH_KEY(val, cmd, event->run_list, i) {
 enum udev_builtin_cmd builtin_cmd = PTR_TO_INT(val);
 char command[UTIL_PATH_SIZE];
 
diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c
index 1c00dd1e9e..cfbbd7b283 100644
--- a/src/udev/udev-node.c
+++ b/src/udev/udev-node.c
@@ -272,7 +272,7 @@ int udev_node_update_old_links(sd_device *dev, sd_device *dev_old) {
 
 static int node_permissions_apply(sd_device *dev, bool apply,
   mode_t mode, uid_t uid, gid_t gid,
-  Hashmap *seclabel_list) {
+  OrderedHashmap *seclabel_list) {
 const char *devnode, *subsystem, *id_filename = NULL;
 struct stat stats;
 dev_t devnum;
@@ -318,7 +318,7 @@ static int node_permissions_apply(sd_device *dev, bool apply,
 log_device_debug(dev, "Preserve permissions of %s, %#o, uid=%u, gid=%u", devnode, mode, uid, gid);
 
 /* apply SECLABEL{$module}=$label */
-HASHMAP_FOREACH_KEY(label, name, seclabel_list, i) {
+ORDERED_HASHMAP_FOREACH_KEY(label, name, seclabel_list, i) {
 int q;
 
 if (streq(name, "selinux")) {
@@ -386,7 +386,7 @@ static int xsprintf_dev_num_path_from_sd_device(sd_device *dev, char **ret) {
 
 int udev_node_add(sd_device *dev, bool apply,
   mode_t mode, uid_t uid, gid_t gid,
-  Hashmap *seclabel_list) {
+  OrderedHashmap *seclabel_list) {
 const char *devnode, *devlink;
 _cleanup_free_ char *filename = NULL;
 int r;
diff --git a/src/udev/udev-node.h b/src/udev/udev-node.h
index 223c8f0e43..5ae816d66f 100644
--- a/src/udev/udev-node.h
+++ b/src/udev/udev-node.h
@@ -10,6 +10,6 @@
 
 int udev_node_add(sd_device *dev, bool a

Bug#925190: udev: Random execution order of RUN commands

[Celelibi]

It looks like it's actually already fixed upstream.
https://github.com/systemd/systemd/issues/11368
Fixed by the commit:
https://github.com/systemd/systemd/commit/39a15c8a8dad26deda140867f03e44a535b7bd8d

> Versions of packages udev is related to:
> ii  systemd  241-1

By looking at the debian source, it looks like it's also fixed in 242-2.
I'll test it when I can, but I think it should work.

Bug#925190: udev: Random execution order of RUN commands

[Celelibi]

Package: udev
Version: 241-2
Severity: important

Dear Maintainer,

It looks like the udev RUN commands are executed in a random order. This
can have catastrophic consequences during boot.

For instance, 69-bcache.rules as provided by bcache-tools try to load
the kernel module with a RUN{builtin} command, and then try to use it
with a RUN command. More often than not, the module is loaded after the
second command is run and the file system isn't mounted.

A simple example of this behavior can be demonstrated by creating a file
/etc/udev/rules/99-foobar.rules containing:
RUN+="foo"
RUN+="bar"

Then run several times:
$ udevadm test /class/input/input0

It should show that the order of "foo" and "bar" isn't deterministic.

Best regards,
Celelibi


-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser   3.118
ii  dpkg  1.19.5
ii  libacl1   2.2.53-4
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-8
ii  libkmod2  26-1
ii  libselinux1   2.8-1+b1
ii  libudev1  241-2
ii  lsb-base  10.2019031300
ii  systemd-sysv  241-1
ii  util-linux2.33.1-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  241-1

-- no debconf information
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:
E: USEC_INITIALIZED=5014384
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXCPU:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=5016848
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXCPU:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=5018440
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: USEC_INITIALIZED=5020201
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input13
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input13
E: SUBSYSTEM=input
E: PRODUCT=19/0/1/0
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PROP=0
E: EV=3
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: USEC_INITIALIZED=5901606
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: TAGS=:seat:

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input13/event6
N: input/event6
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input13/event6
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event6
E: MAJOR=13
E: MINOR=70
E: USEC_INITIALIZED=6220175
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: XKBMODEL=pc105
E: XKBLAYOUT=fr
E: XKBVARIANT=oss
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=19/0/1:LNXPWRBN/button
E: TAGS=:power-switch:

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:
E: USEC_INITIALIZED=5023252
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/ATK0100:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ATK0100:00
E: SUBSYSTEM=acpi
E: DRIVER=Asus Laptop Support
E: MODALIAS=acpi:ATK0100:
E: USEC_INITIALIZED=5030810
E: ID_VENDOR_FROM_DATABASE=Allied Telesyn Int'l

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0A03:
E: USEC_INITIALIZED=5029750
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/ACPI0003:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/ACPI0003:00
E: SUBSYSTEM=acpi
E: DRIVER=ac
E: MODALIAS=acpi:ACPI0003:
E: USEC_INITIALIZED=5034908
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/ACPI0003:00/power_supply/AC0
L: 0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/ACPI0003:00/power_supply/AC0
E: SUBSYSTEM=power_supply
E: POWER_SUPPLY_NAME=AC0
E: POWER_SUPPLY_ONLINE=1

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C02:05
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C02:05
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0C02:
E: USEC_INITIALIZED=5038966
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00

Bug#925126: bcache-tools: Load bcache kernel module *before* registering device

[Celelibi]

Package: bcache-tools
Version: 1.0.8-3
Severity: important

Dear Maintainer,

Recently my computer wasn't booting anymore. It turns out udev was
trying to call the program bcache-register before the kernel module was
loaded. Resulting in a failure to register the device, which then
couldn't be mounted.

The udev rules contain those two lines:
RUN{builtin}+="kmod load bcache"
RUN+="bcache-register $tempnode"

I don't know if udev relaxed the order between actions RUN{builtin} and
RUN. But right now, the order in which they are run is random.

If this is not a bug from udev, then I might suggest splitting
69-bcache.rules into 68-bcache-load.rules and 69-bcache-register.rules
in order to force the execution order.

Best regards,
Celelibi

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

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

Versions of packages bcache-tools depends on:
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-8
ii  libuuid1   2.33.1-0.1

Versions of packages bcache-tools recommends:
ii  initramfs-tools [linux-initramfs-tool]  0.133

bcache-tools suggests no packages.

-- no debconf information

Bug#922877: boolector: Upgrade boolector

[Celelibi]

Package: boolector
Version: 1.5.118.6b56be4.121013-1+b1
Severity: normal

Dear Maintainer,


Could you please consider upgrading the packaged version of boolector?
I guess it was frozen to version 1.5.118 because of the license change.
But the version 3.0 is now under the MIT license, which is
Debian-compatible AFAIK.

Best regards,
Celelibi


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

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

Versions of packages boolector depends on:
ii  libc6  2.28-7

boolector recommends no packages.

boolector suggests no packages.

-- no debconf information

Bug#922876: lua5.3: Please provide a 'lua' metapackage package that depends on the latest version

[Celelibi]

Package: lua5.3
Version: 5.3.3-1.1
Severity: normal

Dear Maintainer,

Having a "lua" metapackage that installs the latest version of lua would
allow to have the latest interpreter automatically updated. This seems
to be a pretty common thing to do in Debian with interpreters and
compilers.

Best regards,
Celelibi

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

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

Versions of packages lua5.3 depends on:
ii  libc6 2.28-7
ii  libreadline7  7.0-5

lua5.3 recommends no packages.

lua5.3 suggests no packages.

-- no debconf information

Bug#783396: python-irc: New upstream version 16.4

[Celelibi]

if I might bump this bug report.
Next week, the current version will be 5 years old, and it misses some
intersting features, like the support for asyncio.

I'm pretty sure there's a simple way to package all the modules needed
by the new version of irc.

Best regards,
Celelibi

Bug#903198: flowblade: Require libmlt-data

[Celelibi]

Package: flowblade
Version: 1.16-1
Severity: normal

Dear Maintainer,

The package libmlt-data is only recommended by libmlt6. But flowblade
won't run correctly without it. Therefore I suggest that flowblade
depends on libmlt-data.

Best regards,
Celelibi

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

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

Versions of packages flowblade depends on:
ii  frei0r-plugins1.6.1-2
ii  gir1.2-gdkpixbuf-2.0  2.36.11-2
ii  gir1.2-glib-2.0   1.56.1-1
ii  gir1.2-gtk-3.03.22.30-2
ii  gir1.2-pango-1.0  1.42.1-2
ii  gmic  1.7.9+zart-4.1+b1
ii  librsvg2-common   2.40.20-2
ii  python2.7.15-3
ii  python-cairo  1.16.2-1+b1
ii  python-dbus   1.2.8-2+b1
ii  python-gi 3.28.2-1+b1
ii  python-gi-cairo   3.28.2-1+b1
ii  python-mlt6.8.0+git20180605-1
ii  python-numpy  1:1.14.4-1
ii  python-pil4.3.0-2
ii  swh-plugins   0.4.17-2

flowblade recommends no packages.

flowblade suggests no packages.

-- no debconf information

Bug#896116: games-minesweeper: Should depend on at least one game

[Celelibi]

Package: games-minesweeper
Version: 2.2
Severity: normal

Dear Maintainer,

If the goal of this package is to install mineweeper games, it should
depends on them, not just list them as recommended.

Alternatively, it could depend on a disjunction of the mineweeper games,
so that at least one get installed.

Best regards,
Celelibi

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

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

Versions of packages games-minesweeper depends on:
ii  games-tasks  2.2

Versions of packages games-minesweeper recommends:
pn  ace-of-penguins  
pn  freesweep
pn  sgt-puzzles  
pn  xbomb
pn  xdemineur

Versions of packages games-minesweeper suggests:
pn  aptitude 
pn  gnome-mines  
pn  kmines   

-- no debconf information

Bug#882354: fluxbox: startup leak file descriptor into subprocesses

[Celelibi]

Package: fluxbox
Version: 1.3.5-2+b2
Followup-For: Bug #882354

It seems to be due to my startup script being executable but not having
a shebang.
When bash is run in sh mode, and a script is "exec"uted which doesn't
have a shebang, it might be interpreted as executing code from a pipe or
something. So it keeps the file descriptor open.

I guess this bug report can be closed since the default content for the
startup script has a shebang now.

Best regards,
Celelibi

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

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

Versions of packages fluxbox depends on:
ii  libc6   2.24-17
ii  libfontconfig1  2.12.3-0.2
ii  libfreetype62.8.1-0.1
ii  libfribidi0 0.19.7-1+b1
ii  libgcc1 1:7.2.0-16
ii  libice6 2:1.0.9-2
ii  libimlib2   1.4.8-1
ii  libsm6  2:1.2.2-1+b3
ii  libstdc++6  7.2.0-16
ii  libx11-62:1.6.4-3
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-1+b2
ii  libxinerama12:1.1.3-1+b3
ii  libxpm4 1:3.5.12-1
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  menu2.1.47+b1

Versions of packages fluxbox recommends:
pn  feh | eterm | hsetroot | xloadimage  
pn  xfonts-terminus  

Versions of packages fluxbox suggests:
pn  fbautostart  
pn  fbdesk   
pn  fbpager  

-- no debconf information

Bug#882354: fluxbox: startup leak file descriptor into subprocesses

[Celelibi]

Package: fluxbox
Version: 1.3.5-2+b2
Severity: normal

Dear Maintainer,

It looks like the process started from ~/.fluxbox/startup inherit from
an already opened file descriptor number 3. Incidentally, this file
descriptor allows to read the startup script itself.

Although it's quite a minor bug, it has some security implications since
any child process can read the startup script from the opened file
descriptor. Even if they would normally not be allowed to read the file
itself.

I have not found what causes this file descriptor to exist in the first
place. It might be related to my setup. I would therefore ask for some
input to confirm this bug. It can be checked by running an xterm in the
startup file, and running the following command in it:
$ ls -l /proc/self/fd
Or:
$ cat <&3

Best regards,
Celelibi


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

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

Versions of packages fluxbox depends on:
ii  libc6   2.24-17
ii  libfontconfig1  2.12.3-0.2
ii  libfreetype62.8.1-0.1
ii  libfribidi0 0.19.7-1+b1
ii  libgcc1 1:7.2.0-16
ii  libice6 2:1.0.9-2
ii  libimlib2   1.4.8-1
ii  libsm6  2:1.2.2-1+b3
ii  libstdc++6  7.2.0-16
ii  libx11-62:1.6.4-3
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-1+b2
ii  libxinerama12:1.1.3-1+b3
ii  libxpm4 1:3.5.12-1
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  menu2.1.47+b1

Versions of packages fluxbox recommends:
pn  feh | eterm | hsetroot | xloadimage  
pn  xfonts-terminus  

Versions of packages fluxbox suggests:
pn  fbautostart  
pn  fbdesk   
pn  fbpager  

-- no debconf information

Bug#877893: libpython3.5-stdlib: csv module: Sniffer shouldn't use '.*?' regex

[Celelibi]

Package: libpython3.5-stdlib
Version: 3.5.4-2
Severity: normal

Dear Maintainer,

The csv module has a Sniffer class to try and detect the dialect used by
a given csv file. To do so, at some point (in the method
_guess_quote_and_delimiter), it runs several regular expressions on the
data provided. Unfortunately, the regex are written such that the search
time might grow quadratically with the size of the input when there is
no match.

For instance on the data:
1234,"foobar"
1234,"foobar"
...
1 lines like this

The first regex, roughly simplified to r',".*?",' can take several
seconds on 1 lines, growing like the square of the number of lines.

To avoid this, I might suggest preventing the .*? to match an unescaped
and un-doubled quote.

Best regards,
Celelibi


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

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

Versions of packages libpython3.5-stdlib depends on:
ii  libbz2-1.01.0.6-8.1
ii  libc6 2.24-17
ii  libdb5.3  5.3.28-13.1
ii  liblzma5  5.2.2-1.3
ii  libmpdec2 2.4.2-1
ii  libncursesw5  6.0+20170902-1
ii  libpython3.5-minimal  3.5.4-2
ii  libreadline7  7.0-3
ii  libsqlite3-0  3.20.1-1
ii  libtinfo5 6.0+20170902-1
ii  mime-support  3.60

libpython3.5-stdlib recommends no packages.

libpython3.5-stdlib suggests no packages.

-- no debconf information

Bug#877097: libpython3.5-stdlib: csv module: Try and detect escapechar

[Celelibi]

Package: libpython3.5-stdlib
Version: 3.5.4-2
Severity: wishlist

Dear Maintainer,

In the csv module, there's a Sniffer class that detects the CSV dialect
used in a file. It appears that it doesn't try to detect the escape
character, the character that is used to put a comma or a quote inside a
string.
This could be a very helpful feature to have.

Best regards,
Celelibi


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

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

Versions of packages libpython3.5-stdlib depends on:
ii  libbz2-1.01.0.6-8.1
ii  libc6 2.24-17
ii  libdb5.3  5.3.28-13.1
ii  liblzma5  5.2.2-1.3
ii  libmpdec2 2.4.2-1
ii  libncursesw5  6.0+20170902-1
ii  libpython3.5-minimal  3.5.4-2
ii  libreadline7  7.0-3
ii  libsqlite3-0  3.20.1-1
ii  libtinfo5 6.0+20170902-1
ii  mime-support  3.60

libpython3.5-stdlib recommends no packages.

libpython3.5-stdlib suggests no packages.

-- no debconf information

Bug#875896: python3-rpy2: Missing dependency to python3-jinja2

[Celelibi]

Package: python3-rpy2
Version: 2.9.0-1
Severity: normal

Dear Maintainer,

It looks like the module jinja2 is imported by rpy2. It thus should be
marked as a dependency.

Best regards,
Celelibi

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

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

Versions of packages python3-rpy2 depends on:
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-17
ii  libgomp1   7.2.0-4
ii  libicu57   57.1-6
ii  liblzma5   5.2.2-1.3
ii  libpcre3   2:8.39-4
ii  python33.5.3-3
ii  python3-numpy  1:1.13.1-1
ii  python3-six1.10.0-4
ii  r-base-core3.3.3-1
ii  zlib1g 1:1.2.8.dfsg-5

python3-rpy2 recommends no packages.

Versions of packages python3-rpy2 suggests:
pn  python-rpy-docs  

-- no debconf information

Bug#874652: python3-socketio-client: Set enable_multithread=True when instanciating Websocket

[Celelibi]

Package: python3-socketio-client
Version: 0.6.5-0.1
Severity: normal

Dear Maintainer,

When instanciating the Websocket class through the create_connection
function (in the constructor of the WebsocketTransport class), the flag
enable_multithread should be set to True. The module SocketIO.client
uses a thread to send a heartbeat. On rare occasions, both threads try
to send some data on the same ssl socket at the same time. This lead to
a segmentation fault in the openssl library, thus crashing the python
interpreter.

Regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python3-socketio-client depends on:
ii  python3-requests   2.18.1-1
ii  python3-six1.10.0-4
ii  python3-websocket  0.37.0-2

python3-socketio-client recommends no packages.

python3-socketio-client suggests no packages.

-- no debconf information

Bug#864062: python3-socketio-client: Incomplete handling of websocket closing

[Celelibi]

Package: python3-socketio-client
Version: 0.6.5-0.1
Severity: normal

Dear Maintainer,

When the websocket transport protocol receive a "CLOSE" opcode, then
WebSocket.recv return an empty string. That makes socketIO_client crash
later when WebSocketTransport.recv_packet calls parse_packet_text on an
empty string.

I am not sure whether empty strings should be ignored on the
socketIO_client side or if the WebSocket side should be more informative
about the connection closing. In any case, the current state doesn't
perform very well on that matter.


Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python3-socketio-client depends on:
ii  python3-requests   2.12.4-1
ii  python3-six1.10.0-3
ii  python3-websocket  0.37.0-2

python3-socketio-client recommends no packages.

python3-socketio-client suggests no packages.

-- no debconf information

Bug#863048: python3-socketio-client: Don't use six.b in WebsocketTransport

[Celelibi]

Package: python3-socketio-client
Version: 0.6.5-0.1
Severity: normal

Dear Maintainer,

When receiving data, the WebsocketTransport class calls six.b on the
input packet. In python3, this is implemented as encoding the string
into "latin-1". Which immediately raise an exception if the string
contains non-latin-1 characters.

There's something smelly about the way the packets are parsed. Either we
know it's all text, and we can let the websocket class do the decoding
by looking at the packet opcode. Or we have byte-level suff to do and we
should get the bytes directly from the WebSocket class without letting
it decide it.  Or, as last alternative encode the string as utf-8 if
we're in python3 and got a str object, since the WebSocket class only
decode as utf-8.

First solution:
Remove the call to six.b and just handle the str object instead of
bytes.

Second solution:
Call recv_data() instead of recv() to get packet_text.

Third solution:
if six.PY3 and isinstance(packet_text, str):
packet_text = packet_text.encode("utf-8")


Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python3-socketio-client depends on:
ii  python3-requests   2.12.4-1
ii  python3-six1.10.0-3
ii  python3-websocket  0.37.0-2

python3-socketio-client recommends no packages.

python3-socketio-client suggests no packages.

-- no debconf information

Bug#859213: x11vnc: stack smashing detected: x11vnc terminated

[Celelibi]

Package: x11vnc
Version: 0.9.13-2
Followup-For: Bug #859213

I confirm this bug. Here is the stacktrace I just got:

#0  0xf7ffb425 in __kernel_vsyscall ()
#1  0xf782ddc0 in __libc_signal_restore_set (set=0x9390) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf782f287 in __GI_abort () at abort.c:89
#4  0xf786937f in __libc_message (do_abort=, fmt=) at ../sysdeps/posix/libc_fatal.c:175
#5  0xf78f9d77 in __GI___fortify_fail (msg=0xf79614f5 "stack smashing 
detected") at fortify_fail.c:30
#6  0xf78f9d38 in __stack_chk_fail () at stack_chk_fail.c:28
#7  0x5661a3d4 in __stack_chk_fail_local ()
#8  0x56614b79 in record_CW (ptr=ptr@entry=0x1 , rec_data=rec_data@entry=0x569e0ec0) at xrecord.c:1347
#9  0x56615041 in record_switch (ptr=0x1 , rec_data=0x569e0ec0) at xrecord.c:1387
#10 0xf7c2458a in ?? () from /usr/lib/i386-linux-gnu/libXtst.so.6
#11 0xf7c24a36 in ?? () from /usr/lib/i386-linux-gnu/libXtst.so.6
#12 0xf7adb7ff in ?? () from /usr/lib/i386-linux-gnu/libX11.so.6
#13 0xf7adc24b in _XEventsQueued () from /usr/lib/i386-linux-gnu/libX11.so.6
#14 0xf7acd762 in XPending () from /usr/lib/i386-linux-gnu/libX11.so.6
#15 0xf7c259d8 in XRecordProcessReplies () from 
/usr/lib/i386-linux-gnu/libXtst.so.6
#16 0x565f2706 in check_xrecord_mouse () at userinput.c:2988
#17 check_xrecord () at userinput.c:3164
#18 0x565fdd9d in check_user_input (dt=0.00043401506263762712, 
dtr=0.014273106004111469, tile_diffs=0, cnt=0x9e8c) at userinput.c:5712
#19 0x565c44b0 in watch_loop () at screen.c:4561
#20 0x5656537f in main (argc=, argv=) at 
x11vnc.c:5990


This seems to match perfectly with the patch you linked.

Dear maintainer, please apply this patch soon. Some instances of the bug
are 100% reproducible to me, makeing me unable to open some popup-menus
without crashing x11vnc.

Best regards,
Celelibi


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages x11vnc depends on:
ii  libavahi-client3  0.6.32-2
ii  libavahi-common3  0.6.32-2
ii  libc6 2.24-10
ii  libjpeg62-turbo   1:1.5.1-2
ii  libssl1.1 1.1.0e-1
ii  libvncclient1 0.9.11+dfsg-1
ii  libvncserver1 0.9.11+dfsg-1
ii  libx11-6  2:1.6.4-3
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  openssl   1.1.0e-1
ii  tk8.6.0+9
ii  x11vnc-data   0.9.13-2
ii  zlib1g1:1.2.8.dfsg-5

x11vnc recommends no packages.

x11vnc suggests no packages.

-- no debconf information

Bug#859206: gnuplot: Recompile with more parallel axes

[Celelibi]

Package: gnuplot
Version: 5.0.5+dfsg1-5
Severity: wishlist

Dear Maintainer,

Parallel coordinates is a pretty convenient way to represent
high-dimensional data. However, with only 7 axes, only 7-D data can be
represented, which is a quite low value for "high". :)

Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages gnuplot depends on:
ii  gnuplot-qt [gnuplot-nox]  5.0.5+dfsg1-5

gnuplot recommends no packages.

Versions of packages gnuplot suggests:
pn  gnuplot-doc  

-- no debconf information

Bug#855845: [Pkg-tigervnc-devel] Bug#855845: tigervnc-viewer: Option -LowColourLevel doesn't seem functional

[Celelibi]

2017-02-28 23:07 UTC+01:00, Ola Lundqvist :
> Is it possible to set a lower color level on the server side? Or do you
> want this on only certain clients?
> I'm quite sure you can set the color depth on the server side.


It is probably possible to set the clolor level on the server, but I
would like to set it myself depending on where I connect
from.Especially because I'm better than vnc at determining whether the
connection is slow or fast.

Bug#855845: tigervnc-viewer: Option -LowColourLevel doesn't seem functional

[Celelibi]

2017-02-22 12:54 UTC+01:00, Celelibi <celel...@gmail.com>:
> Package: tigervnc-viewer
> Version: 1.7.0+dfsg-6
> Severity: normal
>
> Dear Maintainer,
>
> When I use the options "-AutoSelect=0 -FullColor=0 -LowColourLevel=1", I
> still get a full color display.
>
> I used to use xvnc4viewer, which worked correctly with this option, so I
> guess it's not a server-side problem.
>
> Best regards,
> Celelibi
>

Actually it looks like tigervnc chooses automatically which block
should have a lower color level, and I would like to force it.

Bug#855850: fluxbox: Head not detected when on distinct GPU

[Celelibi]

Package: fluxbox
Version: 1.3.5-2+b1
Severity: minor

Dear Maintainer,

I have two monitors connected to two distinct GPUs. I setup the second
one with xrandr --setprovideroutputsource. But then, fluxbox doesn't
seem to detect the head with the second monitor.

Maximizing a window always put it on the main monitor, and the command
"sethead" doesn't seem to work.


Best regards,
Celelibi


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages fluxbox depends on:
ii  libc6   2.24-9
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libfribidi0 0.19.7-1
ii  libgcc1 1:6.3.0-6
ii  libice6 2:1.0.9-1+b1
ii  libimlib2   1.4.8-1
ii  libsm6  2:1.2.2-1+b1
ii  libstdc++6  6.3.0-6
ii  libx11-62:1.6.4-3
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.12-1
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  menu2.1.47

Versions of packages fluxbox recommends:
pn  feh | eterm | hsetroot | xloadimage  
pn  xfonts-terminus  

Versions of packages fluxbox suggests:
pn  fbautostart  
pn  fbdesk   
pn  fbpager  

-- no debconf information

Bug#855847: tigervnc-viewer: Add scaling option

[Celelibi]

Package: tigervnc-viewer
Version: 1.7.0+dfsg-6
Severity: wishlist

Dear Maintainer,

When I connect from a computer with a high DPI screen to server with a
regular monitor, everything is too tiny to read. Adding a scaling option
could fix the issue pretty easily.

It could also fix the opposite problem.

Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages tigervnc-viewer depends on:
ii  libc6  2.24-9
ii  libfltk-images1.3  1.3.4-2
ii  libfltk1.3 1.3.4-2
ii  libfontconfig1 2.11.0-6.7
ii  libgcc11:6.3.0-6
ii  libgnutls303.5.8-3
ii  libjpeg62-turbo1:1.5.1-2
ii  libpam0g   1.1.8-3.5
ii  libstdc++6 6.3.0-6
ii  libx11-6   2:1.6.4-3
ii  libxcursor11:1.1.14-1+b1
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

tigervnc-viewer recommends no packages.

Versions of packages tigervnc-viewer suggests:
pn  tigervnc-common  

-- no debconf information

Bug#855845: tigervnc-viewer: Option -LowColourLevel doesn't seem functional

[Celelibi]

Package: tigervnc-viewer
Version: 1.7.0+dfsg-6
Severity: normal

Dear Maintainer,

When I use the options "-AutoSelect=0 -FullColor=0 -LowColourLevel=1", I
still get a full color display.

I used to use xvnc4viewer, which worked correctly with this option, so I
guess it's not a server-side problem.

Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages tigervnc-viewer depends on:
ii  libc6  2.24-9
ii  libfltk-images1.3  1.3.4-2
ii  libfltk1.3 1.3.4-2
ii  libfontconfig1 2.11.0-6.7
ii  libgcc11:6.3.0-6
ii  libgnutls303.5.8-3
ii  libjpeg62-turbo1:1.5.1-2
ii  libpam0g   1.1.8-3.5
ii  libstdc++6 6.3.0-6
ii  libx11-6   2:1.6.4-3
ii  libxcursor11:1.1.14-1+b1
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

tigervnc-viewer recommends no packages.

Versions of packages tigervnc-viewer suggests:
pn  tigervnc-common  

-- no debconf information

Bug#854900: nvidia-profiler should recommend or suggest nvidia-cuda-toolkit

[Celelibi]

Package: nvidia-profiler
Version: 8.0.44-3
Severity: minor

Dear Maintainer,

The manpage nvprof requires the manpage for cuda-binaries, which is
shipped with nvidia-cuda-toolkit. Thus installing nvidia-profiler result
in a broken manpage.

Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages nvidia-profiler depends on:
ii  libc6   2.24-9
ii  libcuinj64-8.0  8.0.44-3
ii  libgcc1 1:6.3.0-5
ii  libstdc++6  6.3.0-5

nvidia-profiler recommends no packages.

nvidia-profiler suggests no packages.

-- no debconf information

Bug#854426: python3-usb: Device.attach_kernel_driver should probably the release interfaces first

[Celelibi]

Package: python3-usb
Version: 1.0.0-1
Severity: minor

Dear Maintainer,

When trying to end properly a program, I try to reattach the kernel
driver to the device. However, this fails if one interface is still
claimed by the program.

Sice pyusb take care of claiming the interfaces, it should probably also
take care of releasing them. Otherwise, calling
device.attach_kernel_device always fail with a "busy" error.

Best regards,
Celelibi

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-usb depends on:
ii  libusb-1.0-0  2:1.0.21-1
pn  python3:any   

python3-usb recommends no packages.

python3-usb suggests no packages.

-- no debconf information

Bug#853077: ifupdown: Don't let dhclient running forever

[Celelibi]

2017-01-30 14:29 UTC+01:00, Guus Sliepen <g...@debian.org>:
> On Sun, Jan 29, 2017 at 04:46:38PM +0100, Celelibi wrote:
>> The interface is therefore marked as configured although it's not.
>
> It is extremely difficult to say when an interface is configured and
> when it is not. Is it when the kernel interface is up? Is it when a
> carrier is detected? Is it when the DHCP client is started? When it has
> at least one IPv4 address? When you can reach your LAN? Gateway? Another
> host on the Internet?
>
> What if your interface really is up, but then suddenly the DHCP server
> stops extending your lease? Or the network connection fails completely?
> Or some router on the Internet that is completely out of your control
> causes your Internet connection to become useless? Should ifupdown then
> consider the interface down again?

Yeah, I get that. But this wasn't the issue I wanted to bring here.
And I don't have a definitive answer as well. But since you ask, here
is my take on this.
To me, an interface is configured (irrespective of ifupdown) when it
got all the configuration it needs to get. Therefore, with ifupdown,
it's either when it has the manual IP / netmask / gataway / etc, or
when the dhclient succeeded in getting a configuration from the
server.
Additionally, with ifupdown, there's also a matter of allowing ifdown
(without --force) to run the post-down hooks to clean up what the
pre-up hooks did, even if the interface couldn't completely get
configured.

If these two don't match, maybe ifupdown need to register a finer
grain state for each interface. Or need to handle the clean up better.

One related question I have in the back of my head is: should ifup run
the post-down hooks when the pre-up hoos succeeded but the actual
network configuration failed? Maybe there's a good reason not to.

>
> Heuristics that work for you might not work for someone else. Ifupdown
> is also not a daemon that is constantly watching what is happening with
> the network, it can only do things once when you run ifup. The current
> behaviour is a best effort. The reason it goes to the background and to
> mark the interface as up is to ensure the computer can continue booting,
> as you already mentioned. The DHCP client is still running in the
> background, so as soon as you do have a good network connection, you
> will get an IP address.
>

It's because ifupdown isn't a daemon that I prefer it over something
like network-manager. :) To me, it's a one-shot configuring tool. ifup
should configure completely an interface within a finite amount of
time or exit with a failure code. Keeping a daemon running is the
background (should it be dhclient) is exactly what I try to avoid.

What if after a few hours dhclient finally get to configure eth0? It
will also mess up the routes that have been set up by the dhclient
running on wlan0, thus breaking everything.

>> The main inconvenience for me is that it floods the logs with useless
>> messages.
>
> Can you give me an example of those messages in your logs? This is maybe
> something that can be improved.

It's dhclient's logs, waking every few minutes and trying to get an IP
address for 60 seconds. I don't have the logs right now, but I'm sure
you know what I'm talking about. I don't think ifupdown can do
anything about those logs, and I don't think this would be the right
solution either. At least for me.

>
>> It is however desirable on laptops to have dhclient exit when the
>> network is not connected. So that the interface would not be marked as
>> configured by ifupdown and even down at the system level.
>
> This has been asked by others as well, but this is also not as easy as
> it seems. With most network cards nowadays, whether wireless or wired,
> the only way to find out if you can connect to the network is by
> actually bringing the network interface up and to wait for a while, and
> for wireless networks you need to try to associate with an access point
> before you know if you can connect to it. You cannot trust the link
> status of an interface that is down.

I have no problem with bringing the kernel interface up to try to get
a reply from a DHCP server. However, I think that this "up but
unconfigured" state should be transient and either lead quickly to to
fully configured state or a down state. After all, ifupdown isn't a
daemon.

IMO, the right workflow would be:
1) Run the pre-up hooks.
2) Run dhclient -1.
3.a) If dhclient succeed, mark the interface as configured for
ifupdown and run the post-up hooks.
3.b) If dhclient failed, bring the kernel interface down (and maybe
run the post-down hooks).

>
>> Maybe it would be nice to add an ifupdown config file, like
>> /etc/ifupdown.conf in which we could add some options? In this file we
>> would either add a "tryonce" opt

Bug#853130: zsh: Incomplete completion list for man -a

[Celelibi]

Package: zsh
Version: 5.3.1-3
Severity: normal

Dear Maintainer,

Since a few weeks (or month now), zsh has hard time completing the
manpages names when the command line features a '-a' option.

Typing in:
man -a [tab]
Shows a suggestion list of only 73 manpages instead of 8086.

Best regards,
Celelibi


-- Package-specific info:
Packages which provide code meant to be sourced in .zshrc:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
  ArchitectureDescription
+++-=-===-===-
un  command-not-found 
(no description available)
un  grml-debootstrap  
(no description available)

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
  ArchitectureDescription
+++-=-===-===-
ii  curl  7.51.0-1  
  i386command line tool for transferring 
data with URL syntax
ii  mpv   0.23.0-1  
  i386video player based on MPlayer/mplayer2
ht  udev  228-4 
  i386/dev/ and hotplug management daemon
ii  youtube-dl2016.12.01-1  
  all downloader of videos from YouTube and 
other sites

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


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages zsh depends on:
ii  dpkg1.18.18
ii  libc6   2.24-8
ii  libcap2 1:2.25-1
ii  libtinfo5   6.0+20161126-1
ii  zsh-common  5.3.1-3

Versions of packages zsh recommends:
ii  libc6 2.24-8
ii  libncursesw5  6.0+20161126-1
ii  libpcre3  2:8.39-2

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information

Bug#853077: ifupdown: Don't let dhclient running forever

[Celelibi]

Package: ifupdown
Version: 0.8.18
Severity: minor

Dear Maintainer,

When an interface is configured with DHCP, ifup runs a dhclient.
However, if there's no network available after a minute, dhclient forks
to the background and continue to run.

The interface is therefore marked as configured although it's not. The
main inconvenience for me is that it floods the logs with useless
messages.

In the past, dhclient has been run with the option -1 to tell it not to
fork and try to configure the interface forever. This has been removed
back in 2013 (by commit 0a1dbee) to fix the bug #694541 because having
the dhclient exit is not desirable for a server.

It is however desirable on laptops to have dhclient exit when the
network is not connected. So that the interface would not be marked as
configured by ifupdown and even down at the system level.

Maybe it would be nice to add an ifupdown config file, like
/etc/ifupdown.conf in which we could add some options? In this file we
would either add a "tryonce" option, or command line options for
specific DHCP clients.
Just a suggestion.


Best regards,
Celelibi


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  iproute2 4.9.0-1
ii  libc62.24-8
ii  lsb-base 9.20161125

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5-3

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- debconf information excluded

Bug#852976: ifupdown: Inverted exit code of ifquery --state

[Celelibi]

Package: ifupdown
Version: 0.8.18
Severity: normal

Dear Maintainer,

It looks like ifquery --state return the opposite exit code of what it's
supposed to.

If the queried interface is up, it will exit with the status code 1. If
one of the queried interface is down or doesn't exist, it exits with
status code 0. It also exits with an error when the queried interface
isn't specified.

This bug has been introduced with the version 0.8.18 (exactly by the
commit c3cf84e) and might break some scripts that rely on the exit code.


Best regards,
Celelibi


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ifupdown depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  iproute2 4.9.0-1
ii  libc62.24-8
ii  lsb-base 9.20161125

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.5-3

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- debconf information excluded

Bug#851448: clonezilla: Check for compressor existence

[Celelibi]

Package: clonezilla
Version: 3.21.13-1
Severity: normal

Dear Maintainer,

It looks like the existence of the compressor is not checked when saving
a partition (or a whole disk, which use the same task_saveparts
function).

I had pxz installed, but it uses pixz. Which make the partition saving
fail with an inexplicit message.

Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages clonezilla depends on:
ii  bc 1.06.95-9+b2
ii  drbl   2.20.11-1
ii  file   1:5.29-2
ii  gdisk  1.0.1-1
ii  pigz   2.3.4-1

Versions of packages clonezilla recommends:
pn  partclone  
pn  partimage  

Versions of packages clonezilla suggests:
ii  cifs-utils  2:6.6-4
ii  openssh-client  1:7.3p1-5

-- no debconf information

Bug#851442: clonezilla: Unhandled spaces in disk serial numbers

[Celelibi]

Package: clonezilla
Version: 3.21.13-1
Severity: normal

Dear Maintainer,

When building the list of devices that can be choosen to backup, the
serial number of every disk is parsed. If one of them contains spaces, a
subsequent call to whiptail fails, leading to an abort with the message:

"Box" is an unknown hard drive device. Program terminated!.


Here is the serial number on my system (not sure if that's expected).
$ udevadm info -q env -n /dev/nvme0n1 | grep ID_SERIAL=
ID_SERIAL=PM961 NVMe SAMSUNG 512GB_  S33YNX0HB18834


I would suggest that the function get_disk_serial_no in the file
/usr/share/drbl/sbin/ocs-functions replaces spaces with underscores.
Maybe adding something like that before exiting would be enough.
  serialno="$(echo $serialno | tr ' ' _ 2>/dev/null)"


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages clonezilla depends on:
ii  bc 1.06.95-9+b2
ii  drbl   2.20.11-1
ii  file   1:5.29-2
ii  gdisk  1.0.1-1
ii  pigz   2.3.4-1

Versions of packages clonezilla recommends:
pn  partclone  
pn  partimage  

Versions of packages clonezilla suggests:
ii  cifs-utils  2:6.6-4
ii  openssh-client  1:7.3p1-5

-- no debconf information

Bug#850962: screen: Add support for mouse events in large screens

[Celelibi]

Package: screen
Version: 4.4.0-6
Severity: minor
Tags: upstream

Dear Maintainer,

When screen runs in a wide terminal, mouse events are not forwarded to
the application past the 223rd column.

vim inside xterm works fine. When screen is in-between, the clicks on
the far right just don't work.

Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages screen depends on:
ii  libc6  2.24-8
ii  libpam0g   1.1.8-3.4
ii  libtinfo5  6.0+20161126-1

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  
pn  ncurses-term

-- debconf information:
* screen/410-upgrade:
  screen/old_upgrade_prompt: false
  screen/403-copy-failed:

Bug#850568: popularity-contest: popcon-largest-unused tries to read encrypted log

[Celelibi]

Package: popularity-contest
Version: 1.64
Severity: normal

Dear maintainer,

I'm not sure when this happened, but it looks like the statistics
gathered by popularity-contest are not encrypted before sending them
online.

However, the tool popcon-largest-unused (provided by this package) try
to read this file as if it were not encrypted.

I may suggest that popcon-largest-unused reads from
/var/log/popularity-contest.new, which is the unencrypted last file.

Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.18

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-128
ii  exim4  4.88-2
ii  exim4-daemon-light [mail-transport-agent]  4.88-2
ii  gnupg  2.1.17-2

Versions of packages popularity-contest suggests:
pn  anacron  

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

Bug#850526: python-colorama: Package description needs rephrasing

[Celelibi]

Package: python-colorama
Version: 0.3.7-1
Severity: minor

Hello,

The package description currently contains the following sentence which
seems incomplete.

"This has the happy side-effect that existing applications or libraries
which already use ANSI sequences to produce colored output on Linux."

What is the side-effect?
If the side-effect is "to produce colord output", then what's the matter
with "existing applications or libraries"?


Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-colorama depends on:
pn  python:any  

python-colorama recommends no packages.

python-colorama suggests no packages.

-- no debconf information

Bug#845059: python-fuse: Please provide a debug package

[Celelibi]

2016-11-23 3:23 UTC+01:00, Celelibi <celel...@gmail.com>:
> 2016-11-22 11:28 UTC+01:00, Sébastien Delafond <s...@debian.org>:
>> As I was looking into adding an explicit python-fuse-dbg package, I
>> recalled that with recent versions of dh, -dbgsym packages are
>> automatically provided on debug.mirrors.debian.org.
>>
>> See:
>>
>>   https://wiki.debian.org/AutomaticDebugPackages
>>   https://lists.debian.org/debian-devel/2009/03/msg00228.html
>>
>> As an end user, all you'd need is a new entry in sources.list, that'd
>> look like:
>>
>>   deb http://debug.mirrors.debian.org/debian-debug/
>> {unstable,testing}-debug
>> main
>>
>> Then you could just apt-get install python-fuse-dbgsym.
>>
>> So I'm inclined to close this bug as wontfix; what do you think ?
>>
>> Cheers,
>>
>> --Seb
>>
>
>
> I'll try this, and if the dbgsym package works fine, I'll agree to
> mark it as wontfix.
>
> Celelibi
>

It seems to work as fine as it could, so I guess this bug report could
be safely marked as wontfix.


Celelibi

Bug#845059: python-fuse: Please provide a debug package

[Celelibi]

2016-11-22 11:28 UTC+01:00, Sébastien Delafond <s...@debian.org>:
> As I was looking into adding an explicit python-fuse-dbg package, I
> recalled that with recent versions of dh, -dbgsym packages are
> automatically provided on debug.mirrors.debian.org.
>
> See:
>
>   https://wiki.debian.org/AutomaticDebugPackages
>   https://lists.debian.org/debian-devel/2009/03/msg00228.html
>
> As an end user, all you'd need is a new entry in sources.list, that'd
> look like:
>
>   deb http://debug.mirrors.debian.org/debian-debug/ {unstable,testing}-debug
> main
>
> Then you could just apt-get install python-fuse-dbgsym.
>
> So I'm inclined to close this bug as wontfix; what do you think ?
>
> Cheers,
>
> --Seb
>


I'll try this, and if the dbgsym package works fine, I'll agree to
mark it as wontfix.

Celelibi

Bug#845059: python-fuse: Please provide a debug package

[Celelibi]

Package: python-fuse
Version: 2:0.2.1-14
Severity: wishlist

Dear maintainer,

I was experiencing some surprising behavior with python-fuse and decided
to trace the function calls with gdb. Python and fuse both have a dbg
package, but python-fuse doesn't.

Please consider adding a package with the debug symbols, the same way
there is one for python-llfuse.

Thanks in advance.

Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-fuse depends on:
ii  fuse  2.9.7-1
ii  libc6 2.24-5
ii  libfuse2  2.9.7-1

python-fuse recommends no packages.

python-fuse suggests no packages.

-- no debconf information

Bug#843496: libgv-python: Wrong symlink name

[Celelibi]

Package: libgv-python
Version: 2.38.0-16
Severity: grave
Justification: renders package unusable

Dear maintainer,

The .so library on i386 is installed at
/usr/lib/python2.7/dist-packages/libgv_python27.i386-linux-gnu.so and
symlinked from /usr/lib/python2.7/dist-packages/_gv.i686-linux-gnu.so.

However, python look for "i386" in the name, not "i686". Here are the
path searched by python.

$ strace -e trace=file python -c 'import gv' 2>&1 | grep 
'/usr/lib/python2.7/dist-packages/_gv.*\.so' | sort -u
open("/usr/lib/python2.7/dist-packages/_gv.i386-linux-gnu.so", 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/_gvmodule.so", O_RDONLY|O_LARGEFILE) = 
-1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/_gv.so", O_RDONLY|O_LARGEFILE) = -1 
ENOENT (No such file or directory)

Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libgv-python depends on:
ii  libc6 2.24-5
ii  libcdt5   2.38.0-16
ii  libcgraph62.38.0-16
ii  libgcc1   1:6.2.0-10
ii  libgvc6   2.38.0-16
ii  libpython2.7  2.7.12-3+b1
ii  libstdc++66.2.0-10
ii  python2.7.11-2
pn  python:any

libgv-python recommends no packages.

libgv-python suggests no packages.

-- no debconf information

Bug#837869: gnuplot: autoscale on y axis buggy with smooth kdensity

[Celelibi]

Package: gnuplot
Version: 5.0.4+dfsg1-3
Severity: normal

Dear maintainer,

It looks like with "smooth kdensity" gnuplot always take the max of the
weights as yrange-max instead of the real max of the plotted function.
Here is an example:

plot 'file.dat' using 1:(1000) smooth kdensity

With these data:
0
100
200

There's an yrange of [0:1000] while the plot itself doesn't exceed the
value 10. The autoscale seems to be completely off.

This bug seems to apply upstream as well.


Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gnuplot depends on:
ii  gnuplot-qt [gnuplot-nox]  5.0.4+dfsg1-3

gnuplot recommends no packages.

Versions of packages gnuplot suggests:
ii  gnuplot-doc  5.0.4+dfsg1-3

-- no debconf information

Bug#837497: wget: Broken output with options --no-verbose --show-progress --progress=dot

[Celelibi]

Package: wget
Version: 1.18-2+b1
Severity: minor

Dear maintainer,

When combining the options --no-verbose --show-progress --progress=dot
for wget, the last printed line indicated the date and URL of the
downloaded file is printed just after the last line of the progress
indicator. See the example below. Adding just a "\n" would be nice.


$ wget --no-verbose --show-progress --progress=dot https://bugs.debian.org/wget 
-O /dev/null

 0K .. .. .. .. .. 59%  129K 0s
50K .. .. .. ...  100%  
199K=0,6s2016-09-12 01:31:31 
URL:https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wget;dist=unstable 
[85487/85487] -> "/dev/null" [1]



Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages wget depends on:
ii  libc62.23-5
ii  libgnutls30  3.5.3-4
ii  libidn11 1.33-1
ii  libnettle6   3.2-1
ii  libpcre3 2:8.39-2
ii  libpsl5  0.14.0-1
ii  libuuid1 2.28.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages wget recommends:
ii  ca-certificates  20160104

wget suggests no packages.

-- no debconf information

Bug#834775: gcc-6: Massive package size increase w.r.t gcc-5

[Celelibi]

It looks like the size increase is due to debug informations in the
ELF file /usr/lib/gcc/i686-linux-gnu/6/lto1. (Same for cc1 in package
cpp-6.)

The debug informations do not seem to be mandatory for a proper use of
gcc. Could this be split into a gcc-6-dbg package in order to reduce
gcc-6 to a saner size?


Best regards,
Celelibi

Bug#834775: gcc-6: Massive package size increase w.r.t gcc-5

[Celelibi]

Package: gcc-6
Version: 6.1.1-11
Severity: normal

Dear maintainer,

The package gcc-5 used to take up only 24 MB of disk space, while gcc-6
now takes almost 120 MB. That's near a 100 MB increase. It seems really
unreasonable for "just a compiler".

Would it be possible to investigate what takes so much disk space and
possibly reduce the disk usage ?
Maybe by splitting some stuff into a recommended / suggested packages.


Thanks in advance.
Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-6 depends on:
ii  binutils  2.26.1-1
ii  cpp-6 6.1.1-11
ii  gcc-6-base6.1.1-11
ii  libc6 2.23-4
ii  libcc1-0  6.1.1-11
ii  libgcc-6-dev  6.1.1-11
ii  libgcc1   1:6.1.1-11
ii  libgmp10  2:6.1.1+dfsg-1
ii  libisl15  0.17.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.4-2
ii  libstdc++66.1.1-11
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.23-4

Versions of packages gcc-6 suggests:
pn  gcc-6-doc 
pn  gcc-6-locales 
pn  gcc-6-multilib
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#826067: python-gi: module gi._gi_cairo not found

[Celelibi]

2016-06-02 11:10 UTC+02:00, Michael Biebl <bi...@debian.org>:
> Am 02.06.2016 um 02:14 schrieb Celelibi:
>> Package: python-gi
>> Version: 3.20.1-1
>> Severity: important
>>
>> The module files installed in /usr/lib/python2.7/dist-packages/gi don't
>> include a non-debug version for _gi_cairo.
>>
>> There is a version compiled with pydebug enabled that is installed. This
>> one is named _gi_cairo.i386-linux-gnu_d.so, with "_d" meaning pydebug is
>> enabled. Since python2 is compiled without pydebug, that makes it unable
>> to find this shared library.
>>
>> In the attached test case, this module is tentatively loaded from the
>> function pygi_struct_foreign_load_module at gi/pygi-foreign.c:70 to
>> convert arguments to a callback python function. The failure to find a
>> suitable "foreign struct converter" is not shown to the user.
>>
>> This bug seriously undermines the ability to use Gtk3 from python2.
>
> Have you tried installing python-gi-cairo?
> It ships here
> python-gi-cairo:
> /usr/lib/python2.7/dist-packages/gi/_gi_cairo.x86_64-linux-gnu.so

Oh my bad, I even forgot to search which package installed
/usr/lib/python2.7/dist-packages/gi/_gi_cairo.i386-linux-gnu_d.so.
It's python-gi-dbg.

Then this bug should be marked as minor and be only about the missing
error message.
python-gi-cairo is only "suggested" by python-gi and the failure to
load the module produce no message whatsoever.

I see the code kinda talks about a TypeError exception. But it looks
like it's never raised.

Or maybe this bug should be maked as invalid and I report another one?

Best regards,
Celelibi

Bug#826067: python-gi: module gi._gi_cairo not found

[Celelibi]

Package: python-gi
Version: 3.20.1-1
Severity: important

The module files installed in /usr/lib/python2.7/dist-packages/gi don't
include a non-debug version for _gi_cairo.

There is a version compiled with pydebug enabled that is installed. This
one is named _gi_cairo.i386-linux-gnu_d.so, with "_d" meaning pydebug is
enabled. Since python2 is compiled without pydebug, that makes it unable
to find this shared library.

In the attached test case, this module is tentatively loaded from the
function pygi_struct_foreign_load_module at gi/pygi-foreign.c:70 to
convert arguments to a callback python function. The failure to find a
suitable "foreign struct converter" is not shown to the user.

This bug seriously undermines the ability to use Gtk3 from python2.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-gi depends on:
ii  gir1.2-glib-2.01.48.0-2
ii  libc6  2.22-7
ii  libffi63.2.1-4
ii  libgirepository-1.0-1  1.48.0-2
ii  libglib2.0-0   2.48.1-1
ii  python 2.7.11-1
pn  python:any 

python-gi recommends no packages.

Versions of packages python-gi suggests:
pn  python-gi-cairo  

-- no debconf information
#!/usr/bin/python

import sys

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
import cairo
import math

def OnDraw(w, cr):
print("OnDraw")
cr.set_source_rgb(1, 1, 0)
cr.arc(320,240,100, 0, 2*math.pi)
cr.fill_preserve()

cr.set_source_rgb(0, 0, 0)
cr.stroke()

cr.arc(280,210,20, 0, 2*math.pi)
cr.arc(360,210,20, 0, 2*math.pi)
cr.fill()

cr.set_line_width(10)
cr.set_line_cap(cairo.LINE_CAP_ROUND)
cr.arc(320, 240, 60, math.pi/4, math.pi*3/4)
cr.stroke()

w = Gtk.Window()
w.set_default_size(640, 480)
a = Gtk.DrawingArea()
w.add(a)

w.connect('destroy', Gtk.main_quit)
a.connect('draw', OnDraw)

w.show_all()

Gtk.main()

Bug#803629: mke2fs: Bad automatic determination of fs size with -E offset

[Celelibi]

2016-05-02 2:44 UTC+02:00, Celelibi <celel...@gmail.com>:
> 2016-05-01 5:50 UTC+02:00, Theodore Ts'o <ty...@mit.edu>:
>> On Sun, Nov 01, 2015 at 08:41:05AM +0100, Celelibi wrote:
>>>
>>> When the file system size is not given, mke2fs determine the appropriate
>>> size by using the size of the support device. However, when the extended
>>> option "offset" is given, it doesn't seem to reduce the fs size to take
>>> the offset into account.
>>>
>>> An actual case of this bug can be when the support "device" is a regular
>>> file and the size of the file system is not given because it's the last
>>> partition in the virtual disk.
>>
>> So this is tricky.  I will grant that if this is a physical disk, and
>> you specify an offset, and mke2fs tries to figure out the size of the
>> physical disk, it shouldn't make a file system which won't work ---
>> and we know the physical device is 10M, and you have specified an
>> offset of 4M, then the file system length should be 6M or the
>> resulting file system will have some real problems.
>>
>> There are two problems with just always reducing the fs size to take
>> the offset into account.
>
> Well, this is not what I suggested. I suggested that the automatic
> determination of the filesystem size (when it's not explicit) should
> subtract the offset from the size of the device or file.

Sorry, this mail was sent unfinished by mistake.

>> No mattter what, it's going to do the wrong thing, because it can't
>> really "automatically figure out the file system size".  (For one
>> thing, mke2fs has no idea whether you are using GPT, or the FAT
>> partition table, or LVM for that matter.)

Obviously. My in my case it was only for the last partition.
I think I will (some day) make a fuse module to mount partitions as a
user and create some "virtual files" mapped to some parts of an actual
file, which would reduce the need for the -E option in mke2fs. But as
of today, specifying an offset is the only "offline" (without running
a VM) way to create a file system in a partition supported by a file.

Some methods exists to mount partitions from a "disk-file" ("raw" VM
image) but I think all of them require root privileges at some point.

>> Only if the file system size is not specified.
That's indeed the scope of my proposed improvement.

>>
>>> 2) Emit a warning when the offset option is given without a file system
>>> size and the support file is a regular file instead of a block device as
>>> it may overwrite subsequent partitions if it's not the last one.
>>
>> Sure, although I think I'll do it *all* the time.  If you are using
>> the offset, you're doing something weird, even if you are using a block
>> device.

*Especially* when using a block device. I have a use case for an
offset with a regular file, but I doubt there's a use case for block
device (although there might).


Celelibi

Bug#803629: mke2fs: Bad automatic determination of fs size with -E offset

[Celelibi]

2016-05-01 5:50 UTC+02:00, Theodore Ts'o <ty...@mit.edu>:
> On Sun, Nov 01, 2015 at 08:41:05AM +0100, Celelibi wrote:
>>
>> When the file system size is not given, mke2fs determine the appropriate
>> size by using the size of the support device. However, when the extended
>> option "offset" is given, it doesn't seem to reduce the fs size to take
>> the offset into account.
>>
>> An actual case of this bug can be when the support "device" is a regular
>> file and the size of the file system is not given because it's the last
>> partition in the virtual disk.
>
> So this is tricky.  I will grant that if this is a physical disk, and
> you specify an offset, and mke2fs tries to figure out the size of the
> physical disk, it shouldn't make a file system which won't work ---
> and we know the physical device is 10M, and you have specified an
> offset of 4M, then the file system length should be 6M or the
> resulting file system will have some real problems.
>
> There are two problems with just always reducing the fs size to take
> the offset into account.

Well, this is not what I suggested. I suggested that the automatic
determination of the filesystem size (when it's not explicit) should
subtract the offset from the size of the device or file.

  First of all, if the user explicitly
> requests the creation of a file system of a specific size, reducing it
> just because an offset was specified doesn't make sense.  For example:
>
>   mke2fs -E offset=8M /tmp/foo.img 2M
>
> If the user asked for a 2M file system, she should get a 2M file
> system.  Certainly creating a file system of size -6M doesn't make any
> sense!
>
> The second problem is that users who try ro rely on this are very
> likely to get them selves in trouble.  For example, what if the user
> had done this instead:
>
> 1) Create a virtual disk
> qemu-img create -f raw testing.img 20M
>
> 2) Create several partitions
> parted -s testing.img mklabel gpt
> parted -s -a none testing.img mkpart ESP fat32 0 4M
> parted -s -a none testing.img mkpart linux ext4 4M 10M
> parted -s -a none testing.img mkpart linux ext4 10M 20M
>
> And now the user does this:
>
> mke2fs -E 4000256 testing.img
>
> No mattter what, it's going to do the wrong thing, because it can't
> really "automatically figure out the file system size".  (For one
> thing, mke2fs has no idea whether you are using GPT, or the FAT
> partition table, or LVM for that matter.)
>
> So in general, the only reliably consistent thing the user can do is
> to always specify the file system size when the specifying the offset
> --- and not trying to do something crazy like subtracting the offset
> from the file system size.
>
>> Proposed solution:
>> 1) Take the offset into account when computing the optimal file system
>> size.
>
> Only if the file system size is not specified.
>
>> 2) Emit a warning when the offset option is given without a file system
>> size and the support file is a regular file instead of a block device as
>> it may overwrite subsequent partitions if it's not the last one.
>
> Sure, although I think I'll do it *all* the time.  If you are using
> the offset, you're doing something weird, even if you are using a block
> device.
>
>  - Ted
>

Bug#811107: gimp: Automatic threshold doesn't work on binarized image

[Celelibi]

Definitely closely related.

I'd however add a test case that I'm not sure the proposed patch would
solve. An image made of two successive gray levels (say, 128 and 129).
The "Auto" threshold should be able to separate them. I think the
proposed patch just lack a "+1" on the final result.

(BTW, aren't we supposed to answer bellow the message we're replying to?)

2016-03-26 16:31 UTC+01:00, Ari Pollak <a...@debian.org>:
> Ah, thanks for the explanation! Do you think this upstream bug describes
> the same problem? https://bugzilla.gnome.org/show_bug.cgi?id=679622
>
> On Sat, Mar 19, 2016 at 8:46 PM Celelibi <celel...@gmail.com> wrote:
>
>> 2016-03-18 23:56 UTC+01:00, Ari Pollak <a...@debian.org>:
>> > I can't seem to reproduce this. Could you provide step-by-step
>> > instructions, starting from opening gimp?
>> >
>>
>> Ok.
>> 1) Open an image. I join one as example, but any may work too.
>> 2) Use the menu Colors > Threshold. Click "auto", then validate with
>> "OK".
>> 3) Use again the menu Colors > Threshold. Click "auto".
>>
>> The automatically choosen threshold is 0 which will make the image
>> completely white while it was already black and white.
>>
>

Bug#811107: gimp: Automatic threshold doesn't work on binarized image

[Celelibi]

Package: gimp
Version: 2.8.16-1
Severity: minor

Dear maintainer,

The automatic threshold computation is available in Colors > Threshold
and then "auto" button.

When applied on an image already binarized (with all pixels either black
or white) it computes a threshold of 0, thus making all the pixels
white.

It seems that this feature use the Otsu's method to determine the
threshold. This method determine two peaks in the histogram and separate
them.

I'm not sure I understand completely Otsu's thresholding algorithm, but
I think the implementation only lacks a "+1" on the choosen threshold.
It seems to me that the code returns the last value that should be black
while the actual binarization code takes the threshold as the first
value to be white. Thus a "+1" should be the only thing needed.

Moreover the current code doesn't seem to be able to return a value 255.
So it should be all good.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gimp depends on:
ii  gimp-data2.8.16-1
ii  libaa1   1.4p5-44
ii  libatk1.0-0  2.18.0-1
ii  libbabl-0.1-00.1.14-1
ii  libbz2-1.0   1.0.6-8
ii  libc62.21-6
ii  libcairo21.14.4-1
ii  libdbus-1-3  1.10.6-1
ii  libdbus-glib-1-2 0.102-1
ii  libexif120.6.21-2
ii  libexpat12.1.0-7
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libgegl-0.3-00.3.4-1
ii  libgimp2.0   2.8.16-1
ii  libglib2.0-0 2.46.2-3
ii  libgs9   9.16~dfsg-2
ii  libgtk2.0-0  2.24.29-1
ii  libgudev-1.0-0   230-2
ii  libice6  2:1.0.9-1+b1
ii  libjasper1   1.900.1-debian1-2.4
ii  libjpeg62-turbo  1:1.4.1-2
ii  libjson-glib-1.0-0   1.0.4-2
ii  liblcms2-2   2.6-3+b3
ii  libmng1  1.0.10+dfsg-3.1+b3
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libpng12-0   1.2.54-1
ii  libpoppler-glib8 0.38.0-2
ii  librsvg2-2   2.40.11-2
ii  libsm6   2:1.2.2-1+b1
ii  libtiff5 4.0.6-1
ii  libwmf0.2-7  0.2.8.4-10.4
ii  libx11-6 2:1.6.3-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.11-1+b1
ii  libxt6   1:1.1.5-1
ii  python-gtk2  2.24.0-4
ii  python2.72.7.11-2
pn  python:any   
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages gimp recommends:
ii  ghostscript  9.16~dfsg-2

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gvfs-backends 
ii  libasound21.0.29-1

-- no debconf information

Bug#808728: gdc: Enable -Wdeprecated with -Wall or -Wextra

[Celelibi]

Package: gdc
Version: 4:5.3.1-1
Severity: normal

Dear maintainer,

Would it be possible to enable the flag -Wdeprecated by default or with
-Wall or -Wextra?

Having some pretty important warnings left out even with -Wall -Wextra
seems doubtful.


Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gdc depends on:
ii  gdc-5  5.3.1-3
ii  libphobos-dev  5.3.1-1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#808724: gdc: "switch" requires a "default" case

[Celelibi]

Package: gdc
Version: 4:5.3.1-1
Severity: normal

Dear maintainer,

The D languages requires that the "switch" statement has a "default"
case. This is supposed to be already implemented in the frontend and
produce a compilation error.

Here is a simple test-case that shouldn't compile:

import std.stdio;
void main() {
switch (1) {
case 0:
break;
}
}


Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gdc depends on:
ii  gdc-5  5.3.1-3
ii  libphobos-dev  5.3.1-1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#807491: gdc: -fmake-deps misses transitive dependencies

[Celelibi]

Package: gdc
Version: 4:5.2.1-8
Severity: normal

Dear maintainer,

It appears that the option of gdc -fmake-deps doesn't include the
indirect dependencies that can occur when a module uses "public import".

Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages gdc depends on:
ii  gdc-5  5.2.1-23
ii  libphobos-dev  5.2.1-8

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#807491: gdc: -fmake-deps misses transitive dependencies

[Celelibi]

2015-12-09 15:48 UTC+01:00, Celelibi <celel...@gmail.com>:
> Package: gdc
> Version: 4:5.2.1-8
> Severity: normal
>
> Dear maintainer,
>
> It appears that the option of gdc -fmake-deps doesn't include the
> indirect dependencies that can occur when a module uses "public import".
>
> Best regards,
> Celelibi

Here is an example:
== main.d ==
import lib1;
Foo x = 42;

== lib1.d ==
module lib1;
public import lib2;

== lib2.d ==
module lib2;
alias Foo = int;

== Output of gdc -fmake-deps ==
$ gdc -fmake-deps -o /dev/null -c main.d
main.o: main.d /usr/lib/gcc/i586-linux-gnu/5/include/d/object.di lib1.d

The expected output would, of course, include lib2.d.


Best regards,
Celelibi

Bug#806690: tecnoballz: Graphical glitch in boss sprite

[Celelibi]

2015-11-30 7:11 UTC+01:00, Celelibi <celel...@gmail.com>:
> Package: tecnoballz
> Version: 0.93.1-6+b1
> Severity: minor
>
> Hello again, :)
>
> One of the boss between areas 4 and 5 has a little dark spot that isn't
> part of the ship. It seems to be located in the bottom right corner of
> the bounding rectangle.
>

Correction: it's the level 6 of area 5. And it's probably because the
bitmap from which the sprites are taken from overlap with some ball
with spikes in the same bitmap.


Celelibi

Bug#806687: Improvement suggestions for Tecnoballz

[Celelibi]

2015-12-02 19:59 UTC+01:00, Markus Koschany <a...@gambaru.de>:
> Hello Celelibi, hello Bruno
>
> thanks for all the playtesting and the improvement suggestions. I am
> forwarding them with this e-mail to Tecnoballz's upstream developer.
> Perhaps he is interested in implementing those features.
>
> https://bugs.debian.org/cgi-bin/806687
>
> https://bugs.debian.org/cgi-bin/806690
>
> https://bugs.debian.org/cgi-bin/806685

Those links are dead. The correct ones are:
https://bugs.debian.org/806687

https://bugs.debian.org/806690

https://bugs.debian.org/806685


Best regards,
Celelibi

Bug#806685: tecnoballz: Add other control methods for the bumpers

[Celelibi]

Package: tecnoballz
Version: 0.93.1-6+b1
Severity: wishlist

Hello there,

I don't know if it's a design choice but I find it hard to control all
the bumpers at once.

The current behavior is that the left-right motion of the cursor is
translated into a left-right motion of the up and down bumpers and to a
down-up (left is down, right is up) motion of the left and right
bumpers.

I was wondering if it would be possible to add other control methods
that could be configured. I have two propositions.
1) All the bumpers could be controlled by the left-right motion of the
cursor as if the whole area was rotated to put this bumper down. So a
left-right motion translate to a down-up on the right bumper, to a
right-left, to a up-down on the left bumper.

2) Use the up-down motion of the cursor to control the left and right
bumpers independently from the up and down bumpers.


That's just a proposition of improvement.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages tecnoballz depends on:
ii  libc6  2.19-22
ii  libgcc11:5.2.1-23
ii  libmikmod3 3.3.8-1
ii  libsdl-image1.21.2.12-5+b5
ii  libsdl-mixer1.21.2.12-11+b1
ii  libsdl1.2debian1.2.15-12
ii  libstdc++6 5.2.1-23
ii  libtinyxml2.6.2v5  2.6.2-3
ii  tecnoballz-data0.93.1-6

tecnoballz recommends no packages.

tecnoballz suggests no packages.

-- no debconf information

Bug#806687: tecnoballz: Gigablitz jauge not reset when non-bottom bumper is hit

[Celelibi]

Package: tecnoballz
Version: 0.93.1-6+b1
Severity: minor

Hello,

Not sure if this is a bug or if it is on purpose.

The gigablitz jauge is reset when the bottom bumper is hit by a ball. I
guess this is to prevent the player from easily clearing the level with
2 gigablitz by blocking the ball vertically.

However, the jauge is not reset when the ball hit any other bumper.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages tecnoballz depends on:
ii  libc6  2.19-22
ii  libgcc11:5.2.1-23
ii  libmikmod3 3.3.8-1
ii  libsdl-image1.21.2.12-5+b5
ii  libsdl-mixer1.21.2.12-11+b1
ii  libsdl1.2debian1.2.15-12
ii  libstdc++6 5.2.1-23
ii  libtinyxml2.6.2v5  2.6.2-3
ii  tecnoballz-data0.93.1-6

tecnoballz recommends no packages.

tecnoballz suggests no packages.

-- no debconf information

Bug#806690: tecnoballz: Graphical glitch in boss sprite

[Celelibi]

Package: tecnoballz
Version: 0.93.1-6+b1
Severity: minor

Hello again, :)

One of the boss between areas 4 and 5 has a little dark spot that isn't
part of the ship. It seems to be located in the bottom right corner of
the bounding rectangle.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages tecnoballz depends on:
ii  libc6  2.19-22
ii  libgcc11:5.2.1-23
ii  libmikmod3 3.3.8-1
ii  libsdl-image1.21.2.12-5+b5
ii  libsdl-mixer1.21.2.12-11+b1
ii  libsdl1.2debian1.2.15-12
ii  libstdc++6 5.2.1-23
ii  libtinyxml2.6.2v5  2.6.2-3
ii  tecnoballz-data0.93.1-6

tecnoballz recommends no packages.

tecnoballz suggests no packages.

-- no debconf information

Bug#806259: closed by Julien Cristau <jcris...@debian.org> (Re: Bug#806259: xserver-xorg: Depends on xserver-xorg-legacy | systemd)

[Celelibi]

On Thu, Nov 26, 2015 at 07:48:04AM +, Debian Bug Tracking System wrote:
> Date: Thu, 26 Nov 2015 08:45:29 +0100
> From: Julien Cristau <jcris...@debian.org>
> To: Celelibi <celel...@gmail.com>, 806259-d...@bugs.debian.org
> Subject: Re: Bug#806259: xserver-xorg: Depends on xserver-xorg-legacy |
>  systemd
> User-Agent: Mutt/1.5.24 (2015-08-30)
> 
> On Thu, Nov 26, 2015 at 00:14:06 +0100, Celelibi wrote:
> 
> > Package: xserver-xorg
> > Version: 1:7.7+12
> > Severity: important
> > 
> > Dear maintainer,
> > 
> > I don't want to install systemd on my computer, but the new version of
> > xserver-xorg want systemd in order to run as a user. To circumvent this,
> > I see a package xserver-xorg-legacy has been added to run xorg as root
> > if needed.
> > 
> > Would it be possible to make xserver-xorg either:
> > - integrate the xorg wrapper in xserver-xorg so that xorg is always run
> >   as root if needed;
> > - make the package depend on xserver-xorg-legacy to achieve the same
> >   effect;
> > - make the package depend on "xserver-xorg-legacy | systemd" so that
> >   the wrapper is only installed if needed?
> > 
> No.  systemd is needed regardless of xserver-xorg-legacy.

No it's not. And I hope it will never be.

My system is the living proof systemd is not needed at all in Debian. I
use sysvinit and am currently running xorg. And the package systemd is
still not installed.


Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  systemd  (no description available)
ii  xserver-xorg   1:7.7+12 i386 X.Org X server


In any case, before I installed xserver-xorg-legacy I was unable to run
xorg. Meaning that the package xserver-xorg doesn't depend on its actual
prerequisites. It is broken and has to be fixed, should it be by adding
a dependency to systemd (even if that would be a huge mistake).


Best regards,
Celelibi

Bug#806259: xserver-xorg: Depends on xserver-xorg-legacy | systemd

[Celelibi]

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

Dear maintainer,

I don't want to install systemd on my computer, but the new version of
xserver-xorg want systemd in order to run as a user. To circumvent this,
I see a package xserver-xorg-legacy has been added to run xorg as root
if needed.

Would it be possible to make xserver-xorg either:
- integrate the xorg wrapper in xserver-xorg so that xorg is always run
  as root if needed;
- make the package depend on xserver-xorg-legacy to achieve the same
  effect;
- make the package depend on "xserver-xorg-legacy | systemd" so that
  the wrapper is only installed if needed?


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils 7.7+2
ii  xkb-data  2.16-1
ii  xserver-xorg-core 2:1.17.3-2
ii  xserver-xorg-input-evdev [xorg-driver-input]  1:2.9.2-1
ii  xserver-xorg-input-kbd [xorg-driver-input]1:1.8.1-1
ii  xserver-xorg-input-mouse [xorg-driver-input]  1:1.9.1-1
ii  xserver-xorg-input-synaptics [xorg-driver-input]  1.8.2-1
ii  xserver-xorg-video-fbdev [xorg-driver-video]  1:0.4.4-1+b3
ii  xserver-xorg-video-radeon [xorg-driver-video] 1:7.6.1-1
ii  xserver-xorg-video-vesa [xorg-driver-video]   1:2.3.4-1

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  11.0.5-1

xserver-xorg suggests no packages.

-- debconf information:
  xserver-xorg/config/device/default-identifier:
* shared/no_known_x-server:
  shared/fontpath/fontserver:
* xserver-xorg/config/inputdevice/mouse/emulate3buttons: false
  shared/multiple_possible_x-servers:
* xserver-xorg/config/monitor/use_sync_ranges: false

Bug#803628: fuseext2: Please add an "offset" option

[Celelibi]

Package: fuseext2
Version: 0.4-1.1
Severity: wishlist

Dear maintainer,

mke2fs supports an "offset" extended option which allow to create a file
system in the partition of a virtual disk. However it currently can't be
mounted with fuseext2.

Here is an example of how it could work :

# Create a disk image of 10MB
qemu-img create -f raw testing.img 10M

# Create a partition table and two partitions
parted -s testing.img mklabel gpt
parted -s -a none testing.img mkpart ESP fat32 0 4M
parted -s -a none testing.img mkpart linux ext4 4M 10M

# Create the ext file system
mke2fs -E offset=4000256 testing.img 6316k

# Mount it using fuseext2
mount.fuseext2 -o offset=4000256 testing.img mount


Thanks in advance.

Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages fuseext2 depends on:
ii  e2fslibs  1.42.13-1
ii  fuse  2.9.4-1
ii  libc6 2.19-22
ii  libfuse2  2.9.4-1

fuseext2 recommends no packages.

fuseext2 suggests no packages.

-- no debconf information

Bug#803629: mke2fs: Bad automatic determination of fs size with -E offset

[Celelibi]

Package: e2fsprogs
Version: 1.42.13-1
Severity: normal

Dear maintainer,

When the file system size is not given, mke2fs determine the appropriate
size by using the size of the support device. However, when the extended
option "offset" is given, it doesn't seem to reduce the fs size to take
the offset into account.

An actual case of this bug can be when the support "device" is a regular
file and the size of the file system is not given because it's the last
partition in the virtual disk.

How to reproduce:
1) Create a virtual disk
qemu-img create -f raw testing.img 10M

2) Create several partitions
parted -s testing.img mklabel gpt
parted -s -a none testing.img mkpart ESP fat32 0 4M
parted -s -a none testing.img mkpart linux ext4 4M 10M

3) Check the file size
-rw-r--r-- 1 celelibi celelibi 10485760 nov.   1 08:32 testing.img

4) Create the ext2 file system
mke2fs -E offset=4000256 testing.img

5) The file size has increased by an mount equal to the offset
-rw-r--r-- 1 celelibi celelibi 14486016 nov.   1 08:32 testing.img


Proposed solution:
1) Take the offset into account when computing the optimal file system
size.
2) Emit a warning when the offset option is given without a file system
size and the support file is a regular file instead of a block device as
it may overwrite subsequent partitions if it's not the last one.



Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.42.13-1
ii  libblkid1   2.27-3
ii  libc6   2.19-22
ii  libcomerr2  1.42.13-1
ii  libss2  1.42.13-1
ii  libuuid12.27-3
ii  util-linux  2.27-3

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  gpart  
ii  parted 3.2-7

-- no debconf information

Bug#798804: make: Please add U flag in the default ARFLAGS

[Celelibi]

This may actually be more a bug for ar (binutils package) which
introduced a behavior that is not backward compatible and forces the
use of the option U that seems quite new and not portable.

Bug #798913 is the bug for binutils / ar.

I don't know what should happen to both of those. But at least one of
them should be fixed. The current state of those both in Debian is
inconsistent.


Celelibi

Bug#799030: make: Normalize path before matching against targets

[Celelibi]

Package: make
Version: 4.0-8.2
Severity: normal

Dear maintainer,

It seems that make is unable to match a prerequisite foo//bar.txt with a
rule target foo/bar.txt and conversely. These double-slashes are common
occurrence when concatenating paths portions.

This is especially annoying when using make to generate directories. It
is unable to match 'dirname' with 'dirname/'. In addition to that the
$(wildcard) function won't generate names with a trailing slash while
the $(dir) function will.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages make depends on:
ii  libc6  2.19-19

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#798804: make: Please add U flag in the default ARFLAGS

[Celelibi]

Package: make
Version: 4.0-8.2
Severity: minor

Dear maintainer,

It looks like the ar program in the binutils package in debian is now
configured with --enable-deterministic-archives, which is fine (I
guess). However, when dealing with archive members, make needs the
timestamp of the file in order to decide to update it or not. With the
current deterministic behavior of ar, the timestamp is always 0.

The following implicit rule will thus always re-add the member to the
archive as it is considered outdated.

(%): %
#  recipe to execute (built-in):
$(AR) $(ARFLAGS) $@ $<

An undue update of a file in an archive may have a cascading effect in
both directions. The targets that depend on the archive will have to be
updated; and the archive members (if determined to be intermediate
files) will have to be rebuilt. Thus making a major part of the project
to be rebuilt for no reason.


Steps to reproduce:
1) Create a file foo.c.
int main(void) {
return 0;
}

2) Create a Makefile.
target: archive.a(foo.o)
echo doing something

3) Run make twice.
$ make
cc-c -o foo.o foo.c
ar rv archive.a foo.o
ar: creating archive.a
a - foo.o
echo doing something
doing something
rm foo.o

$ make
cc-c -o foo.o foo.c
ar rv archive.a foo.o
r - foo.o
echo doing something
doing something
rm foo.o

4) Check that the timestamp of foo.o in archive.a is 0.
$ ar tv archive.a
rw-r--r-- 0/0848 Jan  1 01:00 1970 foo.o



I think the answer "fix your Makefile" is not appropriate for at least
two reasons:
- Make always rely on the timestamps of the file members, so taking the
  risk of not having them devoid completely the point of having implicit
  rules. And not having valid timestamps can only produce buggy cases
  like the one shown above.
- You cannot always fix the Makefiles because it's not always yours, and
  your Makefiles rely on an archive produced by a Makefile you don't
  have control over.

A workaround may be to add ARFLAGS=rvU as argument or environment
variable to make. This may work in some cases, but it's still a bit
hackish to fix from the outside a broken Makefile when a sensful default
value would fix it once for all.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages make depends on:
ii  libc6  2.19-19

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#792331: iceweasel: meta encoding specification not taken into account past 1024 bytes in POST results

[Celelibi]

Package: iceweasel
Version: 38.1.0esr-2
Severity: normal

Dear maintainer,

The bug here is kinda specific and weird, but a test-case is attached. I
apollogise if I don't use the latest version. But this bug has been
there for a while, and it's unlikely to fix itself.

Here is the setup:
- The server send a html content with the header:
Content-Type: text/html
- No encoding specified in the Content-Type header
- This html content is encoded using UTF-8
- The html contains a meta tag specifying the encoding as UTF-8
- This meta tag is paste the first 1024 bytes

Triggering the bug:
- Retrive a html page with a GET request and the afformentioned setup,
  and the charset is detected as UTF-8
- Retrive the same page with a POST request and the afformentioned
  setup, and the charset is detected as windows-1252

I know HTML5 specify that any encoding specification should lie in
completely in the first 1024 bytes, but it's not the case for any
previous (X)HTML specifications. In any case, this difference in
behavior between a GET and POST request is really puzzling. As far as I
tested, it happens both in strict mode (tested with xhtml 1.1 page) and
in quirk mode.


Here I join a test-case that includes a line of php to ensure the right
Content-Type header is sent, a large block of comment to put the meta
tag after the 1024 first bytes, an UTF-8 accented letter, a form with a
POST method.

The size of the comment block is so that removing one byte make the bug
go away.

Best regards,
Celelibi


-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Comment labels greasemonkey-user-script
Status: enabled

Name: Cookies Manager+
Location: ${PROFILE_EXTENSIONS}/{bb6bc1bb-f824-4702-90cd-35e2fb24f25d}
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Dictionnaire français «Classique amp; Réforme 1990»
Location: 
${PROFILE_EXTENSIONS}/fr-classique-reforme1...@dictionaries.addons.mozilla.org
Status: enabled

Name: DOM Inspector
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/inspec...@mozilla.org
Package: xul-ext-dom-inspector
Status: enabled

Name: Element Hiding Helper pour Adblock Plus
Location: ${PROFILE_EXTENSIONS}/elemhidehel...@adblockplus.org.xpi
Status: enabled

Name: En-têtes HTTP en direct
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}
Package: xul-ext-livehttpheaders
Status: enabled

Name: Firebug
Location: ${PROFILE_EXTENSIONS}/fire...@software.joehewitt.com.xpi
Status: enabled

Name: Google Similar Images
Location: ${PROFILE_EXTENSIONS}/nishan.naseer.googimagesea...@gmail.com.xpi
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

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

Name: Modify Headers
Location: ${PROFILE_EXTENSIONS}/{b749fc7c-e949-447f-926c-3f4eed6accfe}.xpi
Status: enabled

Name: Mouse Gestures Redox
Location: ${PROFILE_EXTENSIONS}/{FFA36170-80B1-4535-B0E3-A4569E497DD0}
Status: enabled

Name: NoScript
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Package: xul-ext-noscript
Status: enabled

Name: Tab Mix Plus
Location: ${PROFILE_EXTENSIONS}/{dc572301-7619-498c-a57d-39143191b318}.xpi
Status: enabled

Name: Tamper Data
Location: ${PROFILE_EXTENSIONS}/{9c51bd27-6ed8-4000-a2bf-36cb95c0c947}.xpi
Status: enabled

Name: TinEye Reverse Image Search
Location: ${PROFILE_EXTENSIONS}/tin...@ideeinc.com.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: user-disabled

Name: Web Developer
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{c45c406e-ab73-11d8-be73-000a95be3b12}
Package: xul-ext-webdeveloper
Status: enabled

-- Plugins information
Name: Java(TM) Plug-in 1.6.0_26
Location: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/i386/libnpjp2.so
Package: sun-java6-bin
Status: disabled

Name: Shockwave Flash (11.2.202.425)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled


-- Addons package information
ii  iceweasel  38.1.0esr-2  i386 Web browser based on Firefox
ii  sun-java6-bin  6.26-0squeez i386 Sun Java(TM) Runtime Environment 
ii  xul-ext-dom-in 1:2.0.15-2   all  tool for inspecting the DOM of we
ii  xul-ext-liveht 0.17-4   all  add information about HTTP header
ii  xul-ext-noscri 2.6.9.29-1   all  permissions manager for Iceweasel
ii  xul-ext-webdev 1.2.5+repack all

Bug#788390: libhttp-cookies-perl: set_cookie doesn't append .local

[Celelibi]

Package: libhttp-cookies-perl
Version: 6.01-1
Severity: normal

Dear maintainer,

Several methods of the perl package HTTP::Cookies append .local at the
end of the domain where it doesn't contain a dot. add_cookie_header
performs the cookie lookup with the transformed domain (localhost
become localhost.local), and so does extract_cookies that parse the
response from the server.

But set_cookie, that allows the user to set an additional cookie by
hand, doesn't do this transformation. Thus, a cookie added to the domain
localhost won't be added to the request using add_cookie_header.

The fix should be as trivial as adding the following line in the
begining of the function set_cookie on line 380.

$domain = $domain.local unless $domain =~ /\./;

That way, the behavior of all the functions should be consistent.

Best regards,
Celelibi


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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libhttp-cookies-perl depends on:
ii  libhttp-date-perl 6.02-1
ii  libhttp-message-perl  6.06-1
ii  perl  5.20.2-6

libhttp-cookies-perl recommends no packages.

libhttp-cookies-perl suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731497: apcupsd: /etc/nologin written even when NOLOGON is set to disable

[Celelibi]

Hello there.

It has been more than a year since last update on this bug. What
happened since then? It's annoying to loose all and every ssh
connection because of a power failure.

Best regards,
Celelibi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705740: gprolog: update to newer version

[Celelibi]

Dear Maintainer,

The bug I'm having right now had been fixed upstream. Here I join an
example code that shows the bug in the constraint solver. The code
should be run with:
$ gprolog --init-goal '[adfgvx_gprolog]' --query substitute([X], [A,
B]), A = 0'X, B = 0'D

It says it doesn't find a solution while the obvious solution is X = 53
(= 0'5).

Best regards,
Celelibi

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

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

Versions of packages gprolog depends on:
ii  libc6  2.19-18

Versions of packages gprolog recommends:
pn  gprolog-doc  none

gprolog suggests no packages.

-- no debconf information
:- set_prolog_flag(double_quotes, codes).


alphabet([
	[0'A, 0'A, 0'A],
	[0'B, 0'A, 0'D],
	[0'C, 0'A, 0'F],
	[0'D, 0'A, 0'G],
	[0'E, 0'A, 0'V],
	[0'F, 0'A, 0'X],
	[0'G, 0'D, 0'A],
	[0'H, 0'D, 0'D],
	[0'I, 0'D, 0'F],
	[0'J, 0'D, 0'G],
	[0'K, 0'D, 0'V],
	[0'L, 0'D, 0'X],
	[0'M, 0'F, 0'A],
	[0'N, 0'F, 0'D],
	[0'O, 0'F, 0'F],
	[0'P, 0'F, 0'G],
	[0'Q, 0'F, 0'V],
	[0'R, 0'F, 0'X],
	[0'S, 0'G, 0'A],
	[0'T, 0'G, 0'D],
	[0'U, 0'G, 0'F],
	[0'V, 0'G, 0'G],
	[0'W, 0'G, 0'V],
	[0'X, 0'G, 0'X],
	[0'Y, 0'V, 0'A],
	[0'Z, 0'V, 0'D],
	[0'0, 0'V, 0'F],
	[0'1, 0'V, 0'G],
	[0'2, 0'V, 0'V],
	[0'3, 0'V, 0'X],
	[0'4, 0'X, 0'A],
	[0'5, 0'X, 0'D],
	[0'6, 0'X, 0'F],
	[0'7, 0'X, 0'G],
	[0'8, 0'X, 0'V],
	[0'9, 0'X, 0'X]
]).



substitute_letter(_, _, _, []).
substitute_letter(P, C1, C2, [[A, X1, X2] | Alphabet]) :-
	(P #= A) #= (C1 #= X1 #/\ C2 #= X2),
	substitute_letter(P, C1, C2, Alphabet).


substitute([], []).
substitute([P | PL], [C1, C2 | CL]) :-
	alphabet(Alphabet),
	fd_domain(P, 456),
	fd_domain([C1, C2], ADFGVX),
	substitute_letter(P, C1, C2, Alphabet),
	substitute(PL, CL).

Bug#782557: glogic: Display not updated

[Celelibi]

Package: glogic
Version: 2.6-2
Severity: grave
Justification: renders package unusable

Dear maintainer,

It looks like the main window is not updated when a new component is
added. The only way I found to make it appear is to switch between
maximized and normal window size. I guess this refresh the main area.

Best regards,
Celelibi

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages glogic depends on:
ii  gir1.2-gtk-3.03.14.5-1
ii  python3   3.4.2-2
ii  python3-gi3.14.0-1
ii  python3-gi-cairo  3.14.0-1

glogic recommends no packages.

Versions of packages glogic suggests:
ii  fonts-liberation  1.07.4-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org