Bug#1075987: Acknowledgement (Regression: VLC crashes when seeking in a video after a Debian update)

[Rémi Denis-Courmont]

Le perjantaina 12. heinäkuuta 2024, 23.27.24 EEST nurupo a écrit :
> Hi,
> 
> I have removed the libvdpau-va-gl1 package, which also removed
> vdpau-driver-all, and rebooted for good measure, however the bug still
> persists. So removing libvdpau-va-gl1 did not help.

Your crash logs says this right before the segmentation fault:

[7fff94c190e0] avcodec decoder: Using OpenGL/VAAPI backend 
for VDPAU for hardware decoding

AFAICT, that's the "name" of the "driver" within libvdpau-va-gl1. If it's 
coming from another package then remove that one too. But that would mean you 
have non-Debian stuff causing the crash.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1075987: Acknowledgement (Regression: VLC crashes when seeking in a video after a Debian update)

[Rémi Denis-Courmont]

Hi,

Le perjantaina 12. heinäkuuta 2024, 3.02.16 EEST nurupo a écrit :
> Seeing how there is no reply, I decided to clarify things a bit.
> Hopefully you find it useful.

The fault is most likely with libvdpau-va-gl1. Uninstall it.

Bluntly, I don't understand why Debian insists on shipping that package at 
all. It serves no useful purpose. Literally the only thing it achieves, other 
than occupying disk space is crashing VDPAU-based applications.

AFAICT, that package has *never* worked properly in its entire history.

-- 
レミ・デニ-クールモン
http://www.remlab.net/

Bug#1038590: vlc: Depends on SDL 1.2

[Rémi Denis-Courmont]

tags 1038590 + fixed-upstream
thanks

Le sunnuntaina 18. kesäkuuta 2023, 20.09.12 EEST Simon McVittie a écrit :
> Source: vlc
> Tags: trixie sid
> User: pkg-sdl-maintain...@lists.alioth.debian.org
> Usertags: libsdl1.2
> 
> This package has a Depends or Build-Depends on SDL version 1.2, which
> is unmaintained upstream.

Upstream VLC has dropped SDL almost 3 years ago, but there has not been a 
release since then. It should be fine to just turn it off in the mean time.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1031249: VLC 3.0.18 crash FIXED with downgrade of libva2 libraries to 2.14.0-1

[Rémi Denis-Courmont]

Le sunnuntaina 19. helmikuuta 2023, 19.13.51 EET js jb a écrit :
> I've verified that by downgrading these libva2 libraries from  2.17.0-1 to
> 2.14.0-1, VLC_3.0.18 works fine again: libva-dev=2.14.0-1
> libva-drm2=2.14.0-1
> libva-glx2=2.14.0-1
> libva-wayland2=2.14.0-1
> libva-x11-2=2.14.0-1
> libva2=2.14.0-1
> intel-media-va-driver=22.4.2+dfsg1-2   (downgraded from 23.1.0+dfsg1-1
> only to avoid removing the package). Therefore this bug should be
> reassigned to the libva2 package instead of vlc. thanks,--jack

AFAICT, the bug is caused by vdpau-va-driver, which is no longer in Debian.

But of course, libva should set lay out adequate conflict statements to prevent 
this from causes crashes, and forcing the package to be uninstalled.

-- 
レミ・デニ-クールモン
http://www.remlab.net/

Bug#1026887: vlc.desktop hardcodes path to executable

[Rémi Denis-Courmont]

Le perjantaina 23. joulukuuta 2022, 15.29.08 EET debianuser a écrit :
> Package: vlc
> Severity: normal
> X-Debbugs-Cc: debianu...@gmail.com
> 
> Dear Maintainer,
> 
> /usr/share/applications/vlc.desktop hardcodes path to the executable in
> the line:
> 
> Exec=/usr/bin/vlc --started-from-file %U
> 
> This breaks tools like firejail.
> 
> Instead it should say:
> 
> Exec=vlc --started-from-file %U

Talking as upstream, it used to be that way (until 2011), and users rightfully 
complained that it incorrectly assumed that the VLC binary would be first in 
the search path. Indeed, VLC is far from the only application to put the full 
path there.

Working around limitations of firejail is a non-goal.

IMO, this is wontfix.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1021664: vlc: Automatic hardware acceleration drops most frames

[Rémi Denis-Courmont]

Le keskiviikkona 12. lokakuuta 2022, 18.47.05 EEST Miguel A. Vallejo a écrit :
> Package: vlc
> X-Debbugs-Cc: ea4...@gmail.com
> Version: 3.0.18~rc2-1
> Severity: important
> 
> Dear Maintainer,
> 
> The last available versions of VLC have problems displaying h264 video
> using hardware acceleration.
(...)
> vlc -vvv shows this:

That log shows VLC *not* using video acceleration.

Note that Debian has turned off VA-API support in VLC:
https://bugs.debian.org/1021601

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1021032: vlc: playing videos results in a black screen

[Rémi Denis-Courmont]

Le 8 octobre 2022 16:40:49 GMT+03:00, KeyofBlueS  a écrit 
:
>> It would be interesting to see if it reproduces with VLC <= 3.0.12 and >=
>> 3.0.18~rc1. (...)
>> It could also be something else. I don't pretend to know that.

>I've compiled 3.0.18-rc2 (sorry i wasn't able to build 3.0.12 also), sadly
>it is still reproducible. I really hope that if it's unfixable, at least
>some workaround could take place, i'm not ready to switch to wayland.

In that case, my hypothesis about the X11 protocol problem is invalidated. 
Updating to 3.0.18 won't fix anything and there are no fixes to backport, and 
no (known) patches to revert either.

Note that VLC 3.0 doesn't support Wayland properly anyway. That would require 
VLC 4.0 which is still far from ready for prime time.

Thanks for the testing.

Bug#1021032: vlc: playing videos results in a black screen

[Rémi Denis-Courmont]

Le lauantaina 8. lokakuuta 2022, 12.40.56 EEST KeyofBlueS a écrit :
> Hi all. Let's continue here from #1021140
> 
> 
> It seems this issue it's not completely fixed. Before it was always
> reproducible under any circumstance, when now there are at least two ways
> to always trigger it:

I believe that the issue is not fixed at all.

The symptoms started showing up after Debian updated Qt, and affect only the Qt 
GUI. The last attempt to fix it affected the VA-API video decoding path in such 
a way that it will still *fail* at a different pace than it did before the fix. 
Then it will fallback to VDPAU or to software decoding path.

But it will still fail anyhow, and the exact same failure occurs when playing 
video outside the VLC GUI, which is unaffected. Therefore, I am led to believe 
that this is a race condition that became apparent with the Debian Qt update, 
and partially worked around by the last VA change in the Debian VLC packaging.


It would be interesting to see if it reproduces with VLC <= 3.0.12 and >= 
3.0.18~rc1. If not, then the X11 protocol-level race condition with parenting 
the VLC video window would be the obvious culprit. Unfortunately though, I 
reckon that that is in fact an X11 protocol design issue that is unfixable 
(short of switching to Wayland, basically), though there are potential 
workarounds.

It could also be something else. I don't pretend to know that.

-- 
レミ・デニ-クールモン
http://www.remlab.net/

Bug#1019354: libc6-dev-riscv64-cross: static libc is unusable

[Rémi Denis-Courmont]

Package: libc6-dev-riscv64-cross
Version: 2.34-7cross2
Severity: important

Dear Maintainer,

Even the most trivial C program:
encounters a segmentation crash when linked statically:

# cat << EOF > hello.c
int main(void) { return 0; }
EOF
# riscv64-linux-gnu-gcc -O2 -static hello.c
# qemu-riscv64-static ./a.out

This can be verified both by running the resulting binary under
qemu-riscv64-static or on real RISC-V hardware running the Debian
RISC-V port.

On target hardware, I can get a stack trace in early libc code:

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...
(gdb) run
Starting program: /home/remi/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x0002ce94 in __ctype_init ()
(gdb) bt
#0  0x0002ce94 in __ctype_init ()
#1  0x00023d92 in __libc_early_init ()
Backtrace stopped: frame did not save the PC


There are no such problems with dynamic linking (although in that case
qemu-riscv64-static will obviously refuse to work since it can only
deal with static binaries). There are also no such problems whilst
statically linking Debian libc6 natively on RISC-V: this seems to
affect *only* libc6-dev-riscv64-cross.

This was working fine a few months ago. Not sure when did it break.

Best regards,

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
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) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev-riscv64-cross depends on:
ii  libc6-riscv64-cross   2.34-7cross2
ii  linux-libc-dev-riscv64-cross  5.18.16-1cross2

libc6-dev-riscv64-cross recommends no packages.

libc6-dev-riscv64-cross suggests no packages.

-- no debconf information

Bug#1011949: linux-libc-dev: missing drm/ headers

[Rémi Denis-Courmont]

Package: linux-libc-dev
Version: 5.18-1~exp1
Severity: normal

Dear Maintainer,

The drm/ user-space API headers are missing in linux-libc-dev (at least
on x86-64). They are present in the cross-compilation packages though,
and FWIW, they are also shipped in Ubuntu's versions of linux-libc-dev.

Br,

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
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) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#842513: vlc: immediate crash on launch on powerpc

[Rémi Denis-Courmont]

Control: tags -1 + fixed-upstream

This should now be fixed in VLC master branch. I can try to backport but it 
won't be so straightforward.

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#983250: vlc: Crash when starting to play video under weston / wayland

[Rémi Denis-Courmont]

On Sun, 21 Feb 2021 20:08:05 +0200 Rémi Denis-Courmont  
wrote:
> > Wayland support is spposed to be better with the upcoming vlc 4.0. No
> > idea when that version will be released, though.
> 
> Basic playback should work. The crash looks like a problem within EGL, so
> not clear why you flag this as an upstream bug.

In this case, it seems to be a bug in the VLC Qt Wayland support which is 
notoriously broken. To be fair, the VLC 3.0 configure script does state:
 "Incomplete Wayland support (default disabled)"

It was probably not a good idea to enable it in Debian. VLC 3 should be used 
through XWayland.

-- 
Реми Дёни-Курмон
http://www.remlab.net/

Bug#842613: vlc: should warn when choosing a DVB channel that isn't from the same transponder.

[Rémi Denis-Courmont]

Control: tags -1 + wontfix

On Sun, 30 Oct 2016 20:59:32 +0100 Jiff  wrote:
> Vlc to act the same as Kaffeine: popping a warning up that explains the
> new chosen channel being on another transponder the former recording
> will be stopped, AND (obviously?) allow channel change smoothly when the
> new channel is on the same transponder without any warning and without
> stopping the current recording.

VLC does not know that another pipeline or another process is recording from 
the same tuner if the kernel does not return an error. VLC cannot warn you 
about something that it is not aware of.

VLC can listen on the demux without access to the tuner, in which case you can 
"safely" change channel within the transponder from the Playback menu.

Br,

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

Bug#958250: Use system libjsonparser-dev

[Rémi Denis-Courmont]

Le tiistaina 21. huhtikuuta 2020, 12.59.20 EEST Jonas Smedegaard a écrit :
> > > But anyway, is libjsonparser's upstream still active? No release
> > > since 2014 doesn't suggest that they are. If that is not the case
> > > and we end up with libjsonparser being maintained in Debian, this
> > > means that changing vlc to libjsonparser is not upstreamable. Due to
> > > the size and security history of vlc, I'd like to avoid that.
> 
> A security bug in libjsonparser should be fixed for all consumers of
> that library, not only for VLC.
>
> If upstream project is dead, and VLC discovers and fixes a bug in the
> library, then that bugfix should be forwarded to the Debian package so
> that other consumers benefit from it as well.

As an upstream developer, I would counter that it is up to Debian, 
specifically, the maintainers of the affected package (not VLC) to take bug 
fixes 
if their upstream is dead.

> Only if VLC changes the API of libjsonparser, effectively forking it
> (and that fork is not packaged separately in Debian!) does it make sense
> to keep using an embedded code copy.

In general and overall, VLC has a pretty good track record of enabling Linux 
distros to use system library builds rather than embedded ones.

But to put things back into historical context, libjsonparser was added to 
Debian in 2018. VLC has depended on it since 2012 and it is quite a small 
library, so that's that.

With that said, in this particular case, VLC 4.0 is probably getting rid of 
libjsonparser entirely in favour of a different implementation, so the 
motivation for overhauling the build system around it is pretty much 
nonexistent from the VLC project side.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

Bug#961118: vlc: Rendering issues on scaled display

[Rémi Denis-Courmont]

Control: -1 tags + moreinfo

On Wed, 20 May 2020 12:39:58 +0200 Kyle Robbertze  
wrote:
> Package: vlc
> Version: 3.0.10-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Opening video in VLC on a scaled display causes incorrect rendering to
> occur. Under KDE the window gets broken up badly and the video is purely
> a black screen. Moving it to an unscaled monitor fixes the issue. A
> screenshot is attached. The playlist screen is not affected and renders
> correctly.

TBH, this looks like a bug in Xorg or the WM. Does this affect all video output 
methods and both integrated/embedded and non-embedded video playback?

Br,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#990247: vlc: reproducible builds: Fix passing sort order to tar when generating default.vlt

[Rémi Denis-Courmont]

Control: tags 990247 = upstream

On Wed, 23 Jun 2021 13:24:23 -0700 Vagrant Cascadian  wrote:
> In share/Makefile.am, when creating default.vlt it attempts to detect
> the availability of the tar --sort= option, but then incorrectly passes
> the variable to tar.
> 
> It does not appear to affect the sort order on
> tests.reproducible-builds.org, but it does appear to cause issues when
> testing with reprotest, and so may occur in other situations in the
> wild.
> 
> 
> The attached patch fixes this by passing it as a make variable rather
> than a quoted shell variable.

Such a patch should be submitted upstream but for a start, it does not look 
right to me. Specifically $$tarsort is correct. AFAICT, the problem is that 
predicate for the assignment relies on locale-dependent behaviour and thus 
fails with non-English languages.

Br,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#842513: vlc: immediate crash on launch on powerpc

[Rémi Denis-Courmont]

Hi,

I have submitted an upstream MR to attempt to fix this. But I don't have a 
setup to actually test it. So I would appreciate if someone could try it out:

https://code.videolan.org/videolan/vlc/-/merge_requests/1934

Br,

-- 
Реми Дёни-Курмон
http://www.remlab.net/

Bug#981380: vlc: GPU lockup

[Rémi Denis-Courmont]

Le lauantaina 30. tammikuuta 2021, 14.06.44 EEST Kamil Jonca a écrit :
> Package: vlc
> Version: 3.0.12-1
> Severity: normal
> X-Debbugs-Cc: kjo...@poczta.onet.pl
> 
> To be honest I am not sure if it bug in vlc, and not elsewhere.

VLC cannot cause the GPU, even less the entire system, to crash. This can be 
caused by bugs in the kernel or the firmware, or by hardware faults.

You may want to disable hardware video decoding acceleration to avoid this 
triggering this kind of issue.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1003117: vlc 3.0.16/debian 11.2.0; main error: TLS session handshake timeout

[Rémi Denis-Courmont]

Control: tags -1 + moreinfo

Hi,

Le tiistaina 4. tammikuuta 2022, 15.25.16 EEST beta-tester a écrit :
> to open a network media in VLC, i hit CTRL-N and paste the link in and
> pressed the PLAY button. then after a while an error message pops up:
> Your input can't be opened:
> VLC is unable to open the MRL
> 'https://liveradio.swr.de/sw282p3/swr3/play.mp3'. Check the log for
> details.

This works fine here (with a non-German IP address, by the way).


Does the connection problem affect gnutls-cli as well?

> here the vlc.log
> -- logger module started --
> main: Running vlc with the default interface. Use 'cvlc' to use vlc without
> interface. main: playlist is empty
> main error: TLS session handshake timeout
> main error: connection error: Resource temporarily unavailable
> main error: TLS session handshake timeout
> main error: connection error: Resource temporarily unavailable
> access error: HTTP connection failure
> -- logger module stopped --

This is only showing the errors. Try with 'vlc -vv'.

> here an other try, where the very first try was successful, but the second
> and later tries failed, also this link is maybe geo-locked and only allowed
> for germany:
> https://liveradio.swr.de/sw282p3/swr3/play.mp3
> 
> -- logger module started --
> main: Running vlc with the default interface. Use 'cvlc' to use vlc without
> interface. main: playlist is empty
> http error: local stream 1 error: Cancellation (0x8)
> prefetch error: unimplemented query (264) in control
> -- logger module stopped --

The error here is ostensibly caused by the local user stopping playback.

> https://liveradio.swr.de/sw282p3/swr3/play.mp3
> 
> -- logger module started --
> main: Running vlc with the default interface. Use 'cvlc' to use vlc without
> interface. main: playlist is empty
> main error: TLS session handshake timeout
> main error: connection error: Resource temporarily unavailable
> gnutls error: TLS handshake error: Error in the push function.
> main error: TLS session handshake error
> main error: connection error: Network is unreachable
> access error: HTTP connection failure
> -- logger module stopped --

And this is an failure from the IP routing table returned by the kernel... 
typically caused by actual connectivity problems.

Br,

-- 
レミ・デニ-クールモン
http://www.remlab.net/

Bug#931242: vlc: cannot open files with # in name from playlist

[Rémi Denis-Courmont]

Control: tags -1 + wontfix

Hi,

The hash in a URL is the anchor separator, so what VLC does here is very much 
intended. If you need a hash in a file name in a M3U, you should encode it as 
%23 so that there are no ambiguities.

Br,
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#1009689: playlist recursive expansion not working

[Rémi Denis-Courmont]

Hi,

The --recursive option controls the handling of directories only, and this is 
consistent with the built-in documentation. It is not supposed to affect the 
parsing of playlists in general.

AFAICT, this is working as intended.

Best regards,
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#1010222: RFP: vlc-plugin-pipewire -- Pipewire plugin for the VLC media player framework

[Rémi Denis-Courmont]

Package: wnpp
Severity: wishlist

* Package name: vlc-plugin-pipewire
  Version : 1
  Upstream Author : Rémi Denis-Courmont 
* URL : https://www.remlab.net/vlc-plugin-pipewire/
* License : GPL (v3)
  Programming Lang: C
  Description : Pipewire plugin for the VLC media player framework

This stand-alone plug-in for the VLC media player and LibVLC-based
applications provides seamless integration with the PipeWire service
for audio playback.

Pipewire and (Lib)VLC are already available in Debian.

Bug#1008174: libc6: poll() spuriously returns EINTR

[Rémi Denis-Courmont]

Hi,

Le lauantaina 26. maaliskuuta 2022, 21.34.38 EET Aurelien Jarno a écrit :
> > As far as I understand, POSIX allows (or even requires) thread
> > cancellation to be essentially like a signal interruption, save for
> > ending the thread. But that is *only* from the moment that cancellation
> > is effected. Cancellation cannot be effected while it is disabled by
> > definition, so the behaviour from glibc seems wrong here.
> 
> poll() is a cancellation point. It appears to me that POSIX actually
> allows this behaviour for cancellation points:

I don't think so...

> "The side effects of acting upon a cancellation request while suspended
> during a call of a function are the same as the side effects that may be
> seen in a single-threaded program when a call to a function is
> interrupted by a signal and the given function returns [EINTR]. Any such
> side effects occur before any cancellation cleanup handlers are called."

AFAIU, in POSIX, "acting upon" a cancellation request means to move the 
cancellation request past the pending state, in other words, actually cancel 
the thread. That quote clarifies that the signal-like interruption is observed 
in the cancelled thread flow of execution before the cancellation clean-up 
handlers.

Otherwise the next paragraph would not make much sense, particularly the last 
sentence:

> "Whenever a thread has cancelability enabled and a cancellation request has
> been made with that thread as the target, and the thread then calls any
> function that is a cancellation point (such as pthread_testcancel() or
> read()), the cancellation request shall be acted upon before the function
> returns. If a thread has cancelability enabled and a cancellation request is
> made with the thread as a target while the thread is suspended at a
> cancellation point, the thread shall be awakened and the cancellation
> request shall be acted upon."

> "However, if the thread is suspended at a cancellation point and the event
> for which it is waiting occurs before the cancellation request is acted
> upon, it is unspecified whether the cancellation request is acted upon or
> whether the cancellation request remains pending and the thread resumes
> normal execution."

And it would get even more nonsensical / contradictory in the following 
section:

> "When a cancellation request is acted upon, (...) the thread first disables
> cancellation by setting its cancelability state to PTHREAD_CANCEL_DISABLE
> and its cancelability type to PTHREAD_CANCEL_DEFERRED. The cancelability
> state shall remain set to PTHREAD_CANCEL_DISABLE until the thread has
> terminated."

This paragraph clarifies that cancellation cannot occur recursively / more than 
once per thread.

Assuming that "acting upon a cancellation request" would be permissible with 
cancellation disabled, this sentence would imply that cancellation is disabled 
permanently, and the thread will never get cancelled at all.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#1008174: libc6: poll() spuriously returns EINTR

[Rémi Denis-Courmont]

Package: libc6
Version: 2.34-0experimental3
Severity: important

Dear Maintainer,

In the example below, glibc 2.34 from experimental causes a spurious
EINTR error in the poll() call from the child thread. It seems that
thread cancellation causes the poll() to be spuriously interrupted,
even though the cancellation is explicitly disabled at that time.

As far as I understand, POSIX allows (or even requires) thread
cancellation to be essentially like a signal interruption, save for
ending the thread. But that is *only* from the moment that cancellation
is effected. Cancellation cannot be effected while it is disabled by
definition, so the behaviour from glibc seems wrong here.

This regression is known to break the test suite from the VLC package.
Rolling back to 2.33 from unstable solves the problem.

8<

#include 
#include 
#include 
#include 
#include 
#include 

static void *thread(void *data)
{
int canc;

(void) data;
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &canc);

if (poll(NULL, 0, 2000) < 0) {
perror("Unexpected poll error");
abort();
}
pthread_setcancelstate(canc, NULL);
return NULL;
}

int main(void)
{
pthread_t th;
void *ret;
struct timespec ts = { 0, 100*1000*1000 };

if (pthread_create(&th, NULL, thread, NULL)) {
perror("pthread_create");
return 1;
}


clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL);
pthread_cancel(th);
pthread_join(th, &ret);
assert(ret == NULL);
return 0;
}

>8

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
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) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc-s1  12-20220319-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.2-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.79
pn  glibc-doc  
ii  libc-l10n  2.34-0experimental3
ii  libnss-nis 3.1-4
ii  libnss-nisplus 1.3-4
ii  locales2.33-7

-- debconf information:
* libraries/restart-without-asking: true
  glibc/kernel-too-old:
  glibc/restart-services:
  glibc/kernel-not-supported:
  glibc/restart-failed:
* glibc/upgrade: true
  glibc/disable-screensaver:

Bug#1007204: /usr/bin/make-kpkg: Please add riscv architecture

[Rémi Denis-Courmont]

Package: kernel-package
Version: 13.018+nmu2
Severity: wishlist
File: /usr/bin/make-kpkg

Dear Maintainer,

At this time, make-kpkg refuses to (cross-)build RISC-V kernel images:

debian/ruleset/misc/checks.mk:36: *** Error. I do not know where the kernel 
image goes to [kimagedest undefined] The usual case for this is that I could 
not determine which arch or subarch this machine belongs to. Please specify a 
subarch, and try again..

Though this is not currently an officially supported Debian architecture,
please consider adding the necessary platform support.

Br,

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
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) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kernel-package depends on:
ii  bc   1.07.1-3+b1
ii  binutils 2.38-2
ii  build-essential  12.9
ii  bzip21.0.8-5
ii  dpkg-dev 1.21.1
ii  file 1:5.41-2
ii  gettext  0.21-4
ii  kmod 29-1
ii  po-debconf   1.0.21+nmu1
ii  xmlto0.0.28-2.1
ii  xz-utils [lzma]  5.2.5-2

Versions of packages kernel-package recommends:
ii  cpio   2.13+dfsg-7
pn  docbook-utils  
pn  kernel-common  
pn  uboot-mkimage  

Versions of packages kernel-package suggests:
ii  libncurses-dev  6.3-2
pn  linux-source

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

-- no debconf information

Bug#899384: vlc: Hardware acceleration fails after upgrade to 3.0.2

[Rémi Denis-Courmont]

Le lundi 28 mai 2018, 00:10:42 EEST Antoni Marcinek a écrit :
> Hi,
> 
> I downgraded to 2.2.7-1~deb9u1. As I remembered I can increase the
> speed up to 64x. The messages in the console are the following:
> 
> VLC media player 2.2.7 Umbrella (revision 2.2.7-0-g6e32381286)
> [55798d591178] core libvlc: Running vlc with the default
> interface. Use 'cvlc' to use vlc without interface.
> Failed to open VDPAU backend libvdpau_i965.so: cannot open shared
> object file: No such file or directory
> 
> There is nothing about VA-API, nor profile(3). So I wonder what is going
> on...

VA-API was not automatically probed in VLC 2.2. This is expected.
VDPAU fails, and then VLC falls back to software decoding.

In VLC 3.0, VA-API probing fails due to insufficient hardware capabilities, so 
VLC uses software decoding as well. So no differences.

-- 
Rémi Denis-Courmont

Bug#734100: Fixed in VLC 3.0

[Rémi Denis-Courmont]

Le lauantaina 5. marraskuuta 2016, 10.21.37 EET Forest a écrit :
> I applied my patches to the vlc 2.2.2-5 package in ubuntu 16.04 LTS, and
> have been using the patched build for the past couple months with no
> trouble.  Looks like success to me.
> 
> Comments on the upstream bug report are dismissive of vlc 2.x users.  It
> would be a shame for us to be stuck with broken audio for the next few
> years.
> 
> What must be done to have my patches added to debian's vlc package?

VLC upstream has not approved any patchset on top of VLC 2.2, and the upstream 
solution is very far from trivial to backport.

At least, all the patches for VLC 2.2 that I´ve seen proposed are all known 
broken. That is to say that they do fix the symptoms, but they introduce even 
worse problems that _will_ break VLC for other people.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#841530: vlc: svlc and qvlc in wrong package

[Rémi Denis-Courmont]

Package: src:vlc
Version: 2.2.4-7
Severity: minor

Dear Maintainer,

svlc and qvlc are shell scripts to start VLC with the Skins2 and Qt
user interfaces respectively. Therefore, I think it would make most
sense to move them to the vlc-plugin-skins and vlc-plugin-qt packages.

Likewise the corresponding man page symbolic links.

Br,

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

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

Versions of packages vlc depends on:
ii  dpkg 1.18.10
ii  vlc-bin  2.2.4-7
ii  vlc-l10n 2.2.4-7
ii  vlc-plugin-base  2.2.4-7
ii  vlc-plugin-qt2.2.4-7
ii  vlc-plugin-video-output  2.2.4-7

Versions of packages vlc recommends:
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
pn  vlc-plugin-skins2  
pn  vlc-plugin-video-splitter  
pn  vlc-plugin-visualization   

vlc suggests no packages.

Versions of packages libvlc5 depends on:
ii  dpkg 1.18.10
ii  libc62.24-5
ii  libvlccore8  2.2.4-7

Versions of packages libvlc5 recommends:
ii  libvlc-bin  2.2.4-7

Versions of packages libvlccore8 depends on:
ii  dpkg 1.18.10
ii  libc62.24-5
ii  libdbus-1-3  1.10.12-1
ii  libidn11 1.33-1

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.11-5

Versions of packages vlc-plugin-fluidsynth depends on:
ii  dpkg1.18.10
ii  fluid-soundfont-gm  3.1-5
ii  libc6   2.24-5
ii  libfluidsynth1  1.1.6-3+b1
ii  libvlccore8 2.2.4-7

-- no debconf information

Bug#803868: vlc: FTBFS with FFmpeg 2.9

[Rémi Denis-Courmont]

Hello,

On Tuesday 19 January 2016 20:32:50 Andreas Cadhalpun wrote:
> > But at this point, this is moot for the purpose of this bug report. FFmpeg
> > 2.9 breaks compatibility with VLC regardless of versions. For the time
> > being, if you want something more recent than FFmpeg 2.8, you need VLC
> > 3.0 *and* libav.
> I guess you're referring to your vlc commit e57d32f [1] as a reaction to
> ffmpeg commit 31741ae [2].
> 
> Why did you not disable frame-threading when using hwaccel, as the ffmpeg
> commit message suggests?

I don´t think that it would be that easy at all on VLC side, without breaking 
either hwaccel or threaded decoding. I don´t want to spend my free time on 
this given that libav´s libavcodec still works just fine.

Patch welcome.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#811519: vlc: avio plugin leaks file content

[Rémi Denis-Courmont]

On Tuesday 19 January 2016 19:06:54 Andreas Cadhalpun wrote:
> On 19.01.2016 17:27, Sebastian Ramacher wrote:
> > On 2016-01-19 18:11:01, Rémi Denis-Courmont wrote:
> >> With a carefully crafted URL, the VLC avio plugin can be made to leak
> >> content of local files to remote parties.
> >> The root cause is the same as CVE-2016-1897.
> >> 
> >> See also:
> >> 
> >> https://mailman.videolan.org/pipermail/vlc-devel/2016-January/105718.html
> > 
> > There is nothing to be done in the vlc package. Reassigning to ffmpeg. It
> > needs to be built with --disable-protocol=concat.
> 
> How is CVE-2016-1897 not fully fixed?
> 
> Rémi, please share details about any remaining vulnerability with
> .

This is a VLC vulnerability and I can´t share it with my own self. Besides the 
underlying issue has already been discussed with upstream libav.

There is plenty of information available already to reproduce the problem. I 
don´t want to publish an exact proof-of-concept against "my" own software, 
especially not before VLC 2.2.2 gets released.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#811519: vlc: avio plugin leaks file content

[Rémi Denis-Courmont]

Package: vlc
Version: 2.2.1-5+b1
Severity: grave
Tags: security patch
Justification: user security hole

Dear Maintainer,

With a carefully crafted URL, the VLC avio plugin can be made to leak
content of local files to remote parties.
The root cause is the same as CVE-2016-1897.

See also:

https://mailman.videolan.org/pipermail/vlc-devel/2016-January/105718.html

Best regards,

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

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

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-44
ii  libavcodec-ffmpeg56 7:2.8.5-1
ii  libavutil-ffmpeg54  7:2.8.5-1
ii  libc6   2.21-6
ii  libcaca00.99.beta19-2+b1
ii  libcairo2   1.14.6-1
ii  libegl1-mesa [libegl1-x11]  11.1.1-2
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreetype62.6.1-0.1
ii  libfribidi0 0.19.7-1
ii  libgcc1 1:5.3.1-6
ii  libgl1-mesa-glx [libgl1]11.1.1-2
ii  libgles1-mesa [libgles1]11.1.1-2
ii  libgles2-mesa [libgles2]11.1.1-2
ii  libglib2.0-02.46.2-3
ii  libpulse0   7.1-2
ii  libqt5core5a5.5.1+dfsg-12
ii  libqt5gui5  5.5.1+dfsg-12
ii  libqt5widgets5  5.5.1+dfsg-12
ii  libqt5x11extras55.5.1-3
ii  librsvg2-2  2.40.13-1
ii  libsdl-image1.2 1.2.12-5+b5
ii  libsdl1.2debian 1.2.15-12
ii  libstdc++6  5.3.1-6
ii  libva-drm1  1.6.2-1
ii  libva-x11-1 1.6.2-1
ii  libva1  1.6.2-1
ii  libvlccore8 2.2.1-5+b1
ii  libvncclient1   0.9.10+dfsg-3
ii  libx11-62:1.6.3-1
ii  libxcb-composite0   1.11.1-1
ii  libxcb-keysyms1 0.4.0-1
ii  libxcb-randr0   1.11.1-1
ii  libxcb-shm0 1.11.1-1
ii  libxcb-xv0  1.11.1-1
ii  libxcb1 1.11.1-1
ii  libxext62:1.3.3-1
ii  libxi6  2:1.7.5-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.11-1+b1
ii  vlc-nox 2.2.1-5+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages vlc recommends:
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
ii  xdg-utils  1.1.1-1

vlc suggests no packages.

Versions of packages vlc-nox depends on:
ii  liba52-0.7.4   0.7.4-18
ii  libasound2 1.0.29-1
ii  libass50.13.1-1
ii  libavahi-client3   0.6.32~rc+dfsg-1
ii  libavahi-common3   0.6.32~rc+dfsg-1
ii  libavc1394-0   0.5.4-2
ii  libavcodec-ffmpeg567:2.8.5-1
ii  libavformat-ffmpeg56   7:2.8.5-1
ii  libavutil-ffmpeg54 7:2.8.5-1
ii  libbasicusageenvironment0  2014.01.13-1
ii  libbluray1 1:0.9.2-2
ii  libc6  2.21-6
ii  libcddb2   1.3.2-5
ii  libcdio13  0.83-4.2+b1
ii  libchromaprint01.2-1+b1
ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-11+b1
ii  libdbus-1-31.10.6-1
ii  libdc1394-22   2.2.3-1
ii  libdca00.0.5-7
ii  libdirectfb-1.2-9  1.2.10.0-5.1
ii  libdvbpsi101.3.0-4
ii  libdvdnav4 5.0.3-1
ii  libdvdread45.0.3-1
ii  libebml4v5 1.3.3-1
ii  libfaad2   2.8.0~cvs20150510-1
ii  libflac8   1.3.1-4
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.1-0.1
ii  libfribidi00.19.7-1
ii  libgcc11:5.3.1-6
ii  libgcrypt201.6.4-4
ii  libgnutls-deb0-28  3.3.20-1
ii  libgpg-error0  1.21-1
ii  libgroupsock1  2014.01.13-1
ii  libjpeg62-turbo1:1.4.1-2
ii  libkate1   0.4.1-5
ii  liblircclient0 0.9.0~pre1-1.2
ii  liblivemedia23 2014.01.13-1
ii  liblua5.2-05.2.4-1
ii  libmad00.15.1b-8
ii  libmatroska6v5 1.4.4-1
ii  libmodplug11:0.8.8.5-2
ii  libmpcdec6 2:0.1~r475-1
ii  libmpeg2-4 0.5.1-7
ii  libmtp91.1.10-2
ii  libncursesw5   6.0+20151024-2
ii  libogg01.3.2-1
ii  libopus0

Bug#803868: vlc: FTBFS with FFmpeg 2.9

[Rémi Denis-Courmont]

Hello,

On Friday 08 January 2016 01:01:05 Andreas Cadhalpun wrote:
> The next version of FFmpeg is planned to be released this month
> (and it might be called 3.0 instead of 2.9).
> 
> What are the current release plans for VLC 3.0?

They are unchanged. VLC releases always slips by several months. I´d be very 
surprised if VLC 3.0 actually comes out this semester.

But at this point, this is moot for the purpose of this bug report. FFmpeg 2.9 
breaks compatibility with VLC regardless of versions. For the time being, if 
you want something more recent than FFmpeg 2.8, you need VLC 3.0 *and* libav.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#796173: reportbug: Sound goes away after seeking in VLC

[Rémi Denis-Courmont]

On Friday 30 October 2015 20:16:46 Manolo Díaz wrote:
> VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision
> 2.2.1-0-ga425c42) [006d0398] core libvlc: Running vlc with the
> default interface. Use 'cvlc' to use vlc without interface.
> [007cc5d8] alsa audio output error: cannot set buffer duration:
> Invalid argument [007cc5d8] core audio output error: module not
> functional
> [7f2458c05288] core decoder error: failed to create audio output

That looks like bug 801448, not bug 796173...

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#734100: Fixed in VLC 3.0

[Rémi Denis-Courmont]

On Monday 02 November 2015 00:34:47 Modestas Vainius wrote:
> The end result builds fine and seems to fix the problem on my machine. Not
> sure if patches break anything on 2.2.1 (i.e. if they need anything else
> from 3.0.0 to work properly). Rémi, maybe you could comment on that?

At least 557eaa06 and 5b2de769 are needed too. I can´t really check deeper in 
my free time.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#734100: Fixed in VLC 3.0

[Rémi Denis-Courmont]

reopen 734100
thanks

On Sunday 01 November 2015 22:03:41 Modestas Vainius wrote:
> Hello,
> 
> Sekmadienis 01 Lapkritis 2015 18:10:54 rašė:
> > tags 734100 + fixed-upstream
> > thanks
> > 
> > This should be fixed in upstream VLC 3.0.
> 
> Thanks a lot. Could this package be backported to current packages?

VLC 3.0 is nowhere near release at this point in time. This is up to the 
Debian Multimedia team, not me, but I would not advise uploading it to 
unstable. And I do not know if there are enough human resources to maintain an 
extra VLC 3.0 in experimental.

> This
> problem has been annoying me for a long time and lately it got only worse.
> Unfortunately, increasing dmix buffer has some unwanted side effects in
> other apps (audio-video desync).

Either those other apps are buggy, or dmix is buggy. The audio delay value 
should account for the dmix buffer.

Also, PulseAudio is better at mixing multiple apps.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#734100: Fixed in VLC 3.0

[Rémi Denis-Courmont]

tags 734100 + fixed-upstream
thanks

This should be fixed in upstream VLC 3.0.
-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#798661: libqt5widgets5: regression in 5.5 breaks vlc video playback

[Rémi Denis-Courmont]

tags 798661 + patch
thanks

Upstream bug report has a fix.

--
Rémi Denis-Courmont
http://www.remlab.net/

Bug#790825: Your mail

[Rémi Denis-Courmont]

tags 790825 + moreinfo
thanks

On Thu, 27 Aug 2015 19:41:45 +1000 Julien Goodwin  
wrote:
> This bug also appears to be why konsole (and only konsole) is crashing 
> for me which I had reported as bug 795815.
> 
> The test program Sebastian provides also causes the problem on my system 
> (Lenovo T430, AMD64, systemd, in an XFCE session).
> 
> Sadly the upstream bug simply says "please try with 5.5" which looks to 
> be winding its way through unstable.

It is in unstable now (though it breaks VLC very badly in other ways).
Consider retrying.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#796173: reportbug: Sound goes away after seeking in VLC

[Rémi Denis-Courmont]

found 796173 2.2.0~rc2-1
tags 796173 + moreinfo
thanks

On Wed, 19 Aug 2015 15:03:28 -0700 Kerry Hall  
wrote:
> Package: reportbug
> Version: 6.6.3
> Severity: normal
> 
> Dear Maintainer,
> 
> I try to seek in a video in vlc, but the sound goes away after seeking. If I 
keep seeking, I can randomly get the sound back sometimes.

Are you using PulseAudio or ALSA or ... as output?
Can you please post the logs?

If PulseAudio, this might already be fixed in VLC 2.2.2.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#791735: vlc: VLC no longer works without pulseaudio

[Rémi Denis-Courmont]

On Tue, 7 Jul 2015 16:27:12 -0600 Akkana Peck  wrote:
> Package: vlc
> Version: 2.2.1-2+b1
> Severity: important
> 
> VLC suddenly is no longer able to play audio on systems that don't
> have pulseaudio installed. When I run it on an mp3 file --
> vlc filename.mp3 from the commandline -- it prints on stdout:
> 
> PulseAudio server connection failure

VLC has been doing that ever since it had PulseAudio support (provided that 
the PulseAudio plugin is installed). That never prevented falling back to 
plain ALSA.

> and then just sits there doing nothing. Clicking the play button
> does nothing. It also won't exit: clicking the windowmanager dismiss
> button sometimes makes the window go away, sometimes not, but either
> way it doesn't return control to the terminal where I started it.

That´s most probably got nothing to do with PulseAudio. Without logs and stack 
trace, it is just impossible to guess what went wrong.

> And it would be nice if it gave the user a real error message
> instead of just doing nothing, and exited gracefully without needing
> kill -9.

When a program locks up, it locks up. Not much to do about it.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#801448: Patch

[Rémi Denis-Courmont]

tags 801448 + patch
thanks

Trivial fix: 
http://git.videolan.org/?p=vlc/vlc-2.2.git;a=commitdiff;h=994c11fb4c2d7c6af7b4e406d56fac72e95e7218;hp=e563b2afd5d8df191d4197a57a584e81e5654d01

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#791620:

[Rémi Denis-Courmont]

On Sunday 25 October 2015 00:09:03 Andoru Ekkusu wrote:
> Package: vlc
> Version: 2.2.1-4+b1
> 
> 
> Nope, still happens with QT 5.5.x

That seems to be a problem between QtGUI and your WM. VLC is not involved in 
painting or configuring the window decoration of its main GUI.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#769739: (no subject)

[Rémi Denis-Courmont]

tags 769739 - upstream fixed-upstream
thanks

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#792728: VLC should suggest on browser-plugin-vlc

[Rémi Denis-Courmont]

On Fri, 17 Jul 2015 14:33:46 -0400 John Scott  wrote:
> I think that VLC should suggest browser-plugin-vlc because it is a part of 
> VLC.

Chromium is dropping support for NPAPI and Firefox is to follow suit. Thus I 
don´t think there is much point in recommending or suggesting the browser 
plugin. At least not anymore.

Given that we have no alternatives to offer, I cannot advise people to deploy 
the NPAPI plugin when I know full well that it will stop working sooner rather 
than later. I don´t think Debian and/or VideoLAN can influence the decision to 
deprecate NPAPI.

> Also, most online VLC installation tutorials tell their readers to 
> install both VLC and the browser plugin. Unfortunately, the browser plugin
> has  to be set to manually installed despite VLC being the only reason for
> it being  on the system.

> (After all, browser-plugin-vlc depends on VLC.)

That´s only because of the package split in Debian. In particular, some of the 
LibVLC plugins that the browser plugin needs are in the "vlc" package.

There are no actual dependencies between the VLC browser plugin and the stand-
alone VLC program.


IMHO, this bug should be closed as wontfix.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#744879: (no subject)

[Rémi Denis-Courmont]

tags 744879 + upstream
forwarded 744879 https://trac.videolan.org/vlc/ticket/11144
thanks

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#797207: (no subject)

[Rémi Denis-Courmont]

tags 797207 + fixed-upstream
thanks

Fixed in VLC 2.2.2.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#801457: vlc: Segmentation fault playing a DVD with vdpau

[Rémi Denis-Courmont]

reassign 801457 mesa-vdpau-drivers
thanks

Hello,

On Sunday 11 October 2015 02:20:59 Arthur Marsh wrote:
> When I removed the vdpau libraries for the GPU in use (r600 libraries for
> RS780 GPU), the video played alright, but did give these error messages:
> 
> Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object
> file: No such file or directory [mpeg2video @ 0x7fffc81b8660] ac-tex
> damaged at 1 0
> [mpeg2video @ 0x7fffc81b8660] skipped MB in I frame at 24 9
> [mpeg2video @ 0x7fffc81b8660] skipped MB in I frame at 17 18
> [mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 32 25
> [mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 13 32
(...)

The libavcodec software MPEG2 Video decoder is complaining that the bit stream 
is corrupt.

The R600 driver is probably not robust against invalid bit stream and just 
crashes instead. This is ostensibly a bug in the R600 driver (or in Mesa 
VDPAU), arguably a security issue too...

As to why this occurs while playing a DVD, I don´t. Either there is some 
physical problem, or the content is malformatted (some DVDs are deliberately 
made to crash open-source players, though typically rather targetting 
libdvdnav).

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#801448: vlc: VLC change audio device without obvious reason

[Rémi Denis-Courmont]

tags 801448 = confirmed upstream fixed-upstream
severity 801448 important
thanks

Fixed in VLC 2.2.2.

http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=7ac70075128318c51bbc1c0190482642f7a9226c

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Bug#794983: vlc does weird things with the .lock file

[Rémi Denis-Courmont]

Le samedi 8 août 2015, 20:30:32 sacrificial-spam-addr...@horizon.com a écrit :
> Package: vlc
> Version: 2.2.1-2+b2
> Architecture: i386
> Severity: minor
> 
> Somehow (it may have been a transient error caused by C++ ABI upgrades),
> I ended up with:
> 
> $ ls ~/.config/vlc/
> vlc-qt-interface.conf
> vlc-qt-interface.conf.lock
> vlc-qt-interface.conf.lock.rmlock
> vlc-qt-interface.conf.lock.rmlock.rmlock
> vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock
> vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock
> vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock
> vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
> vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
> ...
> vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.
> rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
> .rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmloc
> k.rmlock.rmlock.rmlock
> 
> and ended up with vlc stuck looping retrying

VLC is not accessing the file directly, and definitely not taking care of 
locking for it. It is the back-end to Qt's QSettings class.

This should probably be reassigned...

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#757462: vlc burns CPU when paused

[Rémi Denis-Courmont]

forwarded 757462 https://trac.videolan.org/vlc/ticket/541
retitle 757462 vlc burns CPU when paused
thanks

VLC 3.0 no longer wakes the CPU up while paused if playing audio only.

It still performs blitting during pause if playing video though.
Correcting upstream bug number for that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#771037: [vlc] intermittent green overlay on video with audio muting when playing youtube videos

[Rémi Denis-Courmont]

tags 771037 + moreinfo
thanks

Le mardi 25 novembre 2014, 23:57:41 Andrew Kane a écrit :
> When invoking vlc via terminal with command line:
> vlc - https://www.youtube.com/watch?v=6hvcjxI3Wa4
> 
> ...the phenomenon does not occur. Maybe the problem is with one or
> more of the options which apparently are specified when the program is
> started from the launcher or menu, but I don't know how to determine
> which.

hexdump -C /proc/$PID/cmdline

> Any guidance will be appreciated :^)

I would rather suspect a bug in your VDPAU driver than in VLC's command 
line...

-- 
Rémi


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

Bug#765969: (no subject)

[Rémi Denis-Courmont]

tags 765969 + fixed-upstream
found 765969 2.2.0~rc2-1
thanks

VLC 2.2.0-rc2-89-gfebaed2 works around this bug.


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

Bug#765969: (no subject)

[Rémi Denis-Courmont]

Le jeudi 18 décembre 2014, 22:30:19 Dirk Griesbach a écrit :
> Am Do, 18. Dez 2014 um 13:06:31 +0300 schrieb Rémi Denis-Courmont:
> > I still consider this a bug in XVideo drivers, but there is a work-around
> > in VLC now. Unfortunately, that means XVideo output will require memory
> > copying. This is not avoidable without a fix for the XVideo drivers
> > (which is unlikely to happen anytime soon).
> 
> Stupid question of mine and regardless of where the bug actually
> originates: Why is this bug triggered with vlc 2.2.x but not with 2.1.x
> where apart from vlc's dependencies the rest of the system is not
> changed a bit?

The bug does occur in VLC 2.1, just in fewer cases.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#765969: (no subject)

[Rémi Denis-Courmont]

   Hello,

Le 2014-12-07 01:37, Francesco Muzio a écrit :

The bug has been debated here
https://trac.videolan.org/vlc/ticket/12622

And here seems to be found a possible patch, not yet applied

https://trac.videolan.org/vlc/attachment/ticket/12622/vlc-2.2-greenline.patch


That patch is incomplete and I suspect it will lead to crashes in some 
cases.


I still consider this a bug in XVideo drivers, but there is a 
work-around in VLC now. Unfortunately, that means XVideo output will 
require memory copying. This is not avoidable without a fix for the 
XVideo drivers (which is unlikely to happen anytime soon).



Probably this bug happen only with libav and not with ffmpeg


So that sentence sounds a lot like trolling libav developers and the 
choice of libav by the Debian multimedia team. I don't know where you 
stand on libav vs ffmpeg, but the green line issue is solely between VLC 
and the XVideo drivers. VLC and at least some XVideo drivers disagree on 
how scaling cropped pictures should be achieved.


--
Rémi Denis-Courmont


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

Bug#765969: Bug#771133: xserver-xorg-video-intel: colored line on right side / bottom of video

[Rémi Denis-Courmont]

Le jeudi 27 novembre 2014, 11:39:52 maximilian attems a écrit :
> xf86-video-intel upstream says:
> "it's a bug in vlc.
> they are supplying an image larger than the surface they wish to scale
> and then complain when the extra pixels are sampled during scaling.
> the issue is that they are not initialising those extra pixels
> correctly - it should be padded." -ickle

That is a rather innovative way to word it.

VLC supplies an image larger than the source rectangle that it wishes to 
scale. The Intel seems to blend pixels from outside the source rectangle.

How is that a VLC bug?!

> Hence keep bugging vlc guys, will close xorg driver bug report.

It is not the first time that someone blames VLC for not working around quirks 
in the Intel graphic drivers.

You can try this work around, which fills invisible pixels that the Intel 
drivers incorrectly blends with the visible pixels.

If Intel cannot provide working XVideo, they should not provide an XVideo 
adapter in X11 (or alternatively, not provide the XVideo extension at all). 
VLC will happily fallback to OpenGL then.

-- 
Rémi>From 10b8ee4a591045e6bab92fb01d7332baf922a41a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?R=C3=A9mi=20Denis-Courmont?= 
Date: Sun, 30 Nov 2014 13:01:59 +0200
Subject: [PATCH] XCB/XVideo: fill invisible padding in pictures

Some brain-damaged XVideo drivers blend pixels outside the source
rectangle and the pixels within the source rectangle around the bottom
and/or right edge. That makes no sense since the source rectangle is
in whole pixels.

This partly works around the driver bug by filling the padding lines
and columns.
---
 modules/video_output/xcb/xvideo.c | 44 +--
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/modules/video_output/xcb/xvideo.c b/modules/video_output/xcb/xvideo.c
index bddc52b..de2e17d 100644
--- a/modules/video_output/xcb/xvideo.c
+++ b/modules/video_output/xcb/xvideo.c
@@ -99,7 +99,8 @@ struct vout_display_sys_t
 };
 
 static picture_pool_t *Pool (vout_display_t *, unsigned);
-static void Display (vout_display_t *, picture_t *, subpicture_t *subpicture);
+static void Prepare (vout_display_t *, picture_t *, subpicture_t *);
+static void Display (vout_display_t *, picture_t *, subpicture_t *);
 static int Control (vout_display_t *, int, va_list);
 static void Manage (vout_display_t *);
 
@@ -583,7 +584,7 @@ static int Open (vlc_object_t *obj)
 vd->info = info;
 
 vd->pool = Pool;
-vd->prepare = NULL;
+vd->prepare = Prepare;
 vd->display = Display;
 vd->control = Control;
 vd->manage = Manage;
@@ -689,6 +690,45 @@ static picture_pool_t *Pool (vout_display_t *vd, unsigned requested_count)
 return p_sys->pool;
 }
 
+/* TODO: factor this out as a helper function for several vouts? */
+static void Prepare (vout_display_t *vd, picture_t *pic, subpicture_t *subpic)
+{
+for (int i = 0; i < pic->i_planes; i++)
+{
+plane_t *p = pic->p + i;
+uint8_t *dst;
+const uint8_t *src;
+
+dst = p->p_pixels + p->i_pitch * p->i_visible_lines;
+src = dst - p->i_pitch;
+
+for (int y = p->i_visible_lines; y < p->i_lines; y++)
+{
+memcpy(dst, src, p->i_pitch);
+dst += p->i_pitch;
+}
+
+dst = p->p_pixels + p->i_visible_pitch;
+src = dst - p->i_pixel_pitch;
+
+for (int y = 0; y < p->i_lines; y++)
+{
+for (int x = p->i_visible_pitch; x < p->i_pitch;
+ x += p->i_pixel_pitch)
+{
+memcpy(dst, src, p->i_pixel_pitch);
+dst += p->i_pixel_pitch;
+}
+
+src += p->i_pitch;
+dst = src + p->i_pixel_pitch;
+}
+}
+
+(void) vd;
+(void) subpic;
+}
+
 /**
  * Sends an image to the X server.
  */
-- 
1.9.1

Bug#768873: vlc: segfault with ASCII-art video output

[Rémi Denis-Courmont]

tags 768873 + upstream fixed-upstream confirmed
thanks

Le dimanche 09 novembre 2014, 21:31:31 Dirk Griesbach a écrit :
> If the ASCII-art video output is used, vlc will crash with a segfault
> when trying to play a video. The colored ASCII-art output plays just
> fine. I've attached a gdb session. This is on an up-to-date unstable
> with an Intel 945GM graphics chipset. VLC 2.15 had both ASCII and
> colored ASCII outputs working properly.

This should be fixed upstream already in 2.2.0-rc1-17-g4b961ac.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#765969: [vlc] green line under some Mpeg-4 XVID videos

[Rémi Denis-Courmont]

tags 765969 + wontfix
thanks

Le vendredi 07 novembre 2014, 23:35:41 Dirk Griesbach a écrit :
> Am Fr, 07. Nov 2014 um 23:17:12 +0100 schrieb Francesco Muzio:
> > what driver/graphics card are you using?
> 
> VGA-compatible devices on PCI bus:
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2]
> (rev 03)

Probably more than one driver is affected. But I did spend several hours 
troubleshooting it on an affected system and so far it does seem like a driver 
bug: the driver is blending the last line of visible pixels with the first line 
of pixels outside the visible area. All zeroes corresponds to dark green in 
YUV colours space.

Now, I´m not flawless, but with no further arguments, I consider this a driver 
bug. Considering how bad of a reputation XVideo has accumulated with GPU 
driver developers, this is not even surprising.

VLC 3.0 is intended to switch to default to OpenGL (GLX) rather than XVideo. 
Debian might consider doing the same in their VLC package. This should work 
around the bug and would also improve scaling of subpictures. But of course, 
it would expose other potential GPU driver bugs.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#765830: (no subject)

[Rémi Denis-Courmont]

forwarded 765830 https://trac.videolan.org/vlc/ticket/12673
tags 765830 + upstream fixed-upstream
found 765830 2.2.0~rc1-1
thanks

This should be fixed in VLC 2.2.0-git *post* RC1.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#763705: vlc: [kfreebsd] quits after ~30 seconds: xdg_screensaver_plugin

[Rémi Denis-Courmont]

reassign 763705 libc0.1
thanks

Hello,

Le lundi 20 octobre 2014, 11:45:40 Rémi Denis-Courmont a écrit :
> Le 2014-10-02 02:11, Steven Chamberlain a écrit :
> > Attached is output from kFreeBSD's ktrace, showing:
> > pid, thread ID, process name, elapsed time (seconds), and syscalls
> 
> In the trace, it looks like SIGCHLD causes sigwait() to return, even
> though SIGCHLD is not in the wait-set.
> 
> If that is the case, then I think it is a bug in the kFreeBSD
> sigwait().

  7296 100634 vlc  48.521557 RET   sigwait 4
  7296 100634 vlc  48.521577 PSIG  SIGCHLD caught handler=0x804254220 
mask=0x5007 code=CLD_EXITED
  7296 100634 vlc  48.521631 CALL  write(0xa,0x804354922,0x1)

It seems that sigwait() returns EINTR, which is not even a specified error for 
sigwait(). What is worst, SIGCHLD is blocked on the calling task.

This is completely bogus behaviour from the run-time as far as I can tell.

Best regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#740998: rdnssd: merge-hook overwrites /etc/resolv.conf when /sbin/resolvconf is not installed

[Rémi Denis-Courmont]

Le lundi 27 octobre 2014, 15:20:37 Raphael Hertzog a écrit :
> On Fri, 07 Mar 2014, Frank Heckenbach wrote:
> > The merge-hook script overwrites /etc/resolv.conf when
> > /sbin/resolvconf is not installed, thereby erasing additional
> > entries in this file such as "name" etc.
> 
> And it also erases non-IPv6 DNS servers that were present
> in that file before.
> 
> Right now, this package got installed by default on a Jessie GNOME
> desktop and it really interacts badly with NetworkManager which
> was handling the file perfectly fine (i.e. it included already the
> IPv6 DNS servers identified by rdnsd).

That *is* a problem. Indeed NetworkManager has gained support for RDNSS for a 
long time already, and thus made completely rdnssd redundant if not counter-
productive on a system with NetworkManager.

But as far as I know, whatever caused this default is not rdnssd itself.

> I believe that it should do something saner instead of overwriting.

I must disagree. If resolvconf is absent, overwriting is the most sane, or 
least insane thing to do. There just is not a lot that can be done without 
mediation for writing the resolver configuration.

> It should verify if the file contains the DNS servers it detected
> and add them if they are missing. But it should definitely not blindly
> overwrite the file...

There are currently no ways to know which entries were inserted by rdnssd 
(possibly by a previous incantation of it) and which by other tools. 
Furthermore, I doubt we can safely assume that all resolv.conf tools remove 
their entries when uninstalled. I think this suggestion is worse than the bug 
from a reliability perspective.

Really, any pair of two tools writing resolv.conf will screw stuff up without 
resolvconf present and supported by both tools. That problem affects ppp, dhcp-
client3, network-manager, wicd, connman, systemd(-networkd) just to name a 
few. And I don´t dare mention most if not all VPN clients.


-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#761165: vlc: segmentation fault with VDPAU

[Rémi Denis-Courmont]

Le mardi 21 octobre 2014, 02:13:00 Arthur Marsh a écrit :
> Package: vlc
> Version: 2.2.0~pre4-1+b1
> Followup-For: Bug #761165
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate
> ***
> 
> See also bug report 766058.
> 
> After running vlc under valgrind both with default options and with
> helgrind, I found the video terminated at the 9 second mark with default
> options but continued playing back very slowly with the helgrind option,
> which someone in #radeon in IRC suggested was a thread race condition in
> vlc.

The helgrind log there suggests a race condition in the Mesa VDPAU´s internal 
buffer object management to me.

And please don´t use VLC with Bellagio. The only tested software decoder is 
libav(codec).

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#763705: vlc: [kfreebsd] quits after ~30 seconds: xdg_screensaver_plugin

[Rémi Denis-Courmont]

Le 2014-10-02 02:11, Steven Chamberlain a écrit :

Attached is output from kFreeBSD's ktrace, showing:
pid, thread ID, process name, elapsed time (seconds), and syscalls


In the trace, it looks like SIGCHLD causes sigwait() to return, even 
though SIGCHLD is not in the wait-set.


If that is the case, then I think it is a bug in the kFreeBSD 
sigwait().


--
Rémi Denis-Courmont


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

Bug#765969: [vlc] green line under some Mpeg-4 XVID videos

[Rémi Denis-Courmont]

Le 2014-10-20 00:28, Francesco Muzio a écrit :

Oops, I have forgotten the screenshot


The video is really low quality so it's hard to say but we can clearly 
see by zooming in that shades of grey are visible in the last lines, 
even though the colour informations is discarded, resulting in a green 
tint. I can't reproduce the problem with X11 or GLX, so I believe this 
is a bug in your display drivers.


--
Rémi Denis-Courmont


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

Bug#761165: vlc: segmentation fault with VDPAU

[Rémi Denis-Courmont]

Le 2014-10-20 11:57, Arthur Marsh a écrit :
I may be able to get permission from the publisher to release perhaps 
the

15 seconds of video from the DVD.


I'm more concerned about the specific driver and hardware than the 
specific DVD.


And that error, while it does not explain the crash, is most definitely 
a driver bug:



[7fffbc001268] vdpau_display vout display error: bitmap surface
creation failure: The size of a supplied object does not match the
object it is being used with.  For example, a VdpVideoMixer is
configured to process VdpVideoSurface objects of a specific size.
If presented with a VdpVideoSurface of a different size, this error
will be raised.


That error code makes absolutely no sense in this context.

--
Rémi Denis-Courmont


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

Bug#761165: vlc: segmentation fault with VDPAU

[Rémi Denis-Courmont]

Le 2014-09-29 04:42, Arthur Marsh a écrit :
I'm still seeing the problem with this version of VLC and can't 
provide a

legal sample as it's from a commercial DVD.

Should this problem be assigned to mesa-vdpau-drivers?


I don't know.

I can't reproduce the problem with any DVD of mine and the NVIDIA 
drivers. The stack frames were not very helpful because they are all 
either incomplete or ostensibly corrupt.


--
Rémi Denis-Courmont


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

Bug#765969: [vlc] green line under some Mpeg-4 XVID videos

[Rémi Denis-Courmont]

Le dimanche 19 octobre 2014, 20:16:34 Francesco Muzio a écrit :
> Package: vlc
> Version: 2.2.0~pre4-1
> Severity: normal

> Some video shows an horizontal green line at the bottom of the video.
> The green line is seen especially if I play a fullscreen 16:9 video on a
> 16:10 (or 4:3, 5:4) screen.

Are the pixel rows at the bottom part obscuring the bottom of the picture or 
are they added extraneous? If obscuring, do they lack colour or do they lack 
both colour and brightness?

Which VLC video output plugin was used and does it affect others?

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#765793: glx-alternative-nvidia: makes EGL applications crash

[Rémi Denis-Courmont]

Package: glx-alternative-nvidia
Version: 0.4.2
Severity: important

Dear Maintainer,

When running 'vlc -Vgl /some/video/file', VLC crashes straight away
if glx-alternative-nvidia is installed. It appears that libGL.so points
(correctly) to the NVIDIA driver, but libEGL.so points to the Mesa
implementation, resulting in a memory corruption.

'export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/nvidia/current' works
around the problem, assuming libegl1-nvidia is installed.

libEGL.so should ostensibly be redirected at the same time as libGL.so.

-- Package-specific info:
Diversions:
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions

/usr/lib/mesa-diverted:
total 52
drwxr-xr-x  5 root root  4096 Mar 22  2014 .
drwxr-xr-x 86 root root 32768 Oct 18 09:55 ..
drwxr-xr-x  2 root root  4096 Oct 24  2013 arm-linux-gnueabihf
drwxr-xr-x  2 root root  4096 Oct 18 09:53 i386-linux-gnu
lrwxrwxrwx  1 root root33 Mar 22  2014 libGL.so-master -> 
/etc/alternatives/libGL.so-master
drwxr-xr-x  2 root root  4096 Oct 18 09:53 x86_64-linux-gnu

/usr/lib/mesa-diverted/i386-linux-gnu/:
total 688
drwxr-xr-x 2 root root   4096 Oct 18 09:53 .
drwxr-xr-x 5 root root   4096 Mar 22  2014 ..
lrwxrwxrwx 1 root root 14 Oct 14 00:57 libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 695836 Oct 14 00:57 libGL.so.1.2.0

/usr/lib/mesa-diverted/x86_64-linux-gnu/:
total 624
drwxr-xr-x 2 root root   4096 Oct 18 09:53 .
drwxr-xr-x 5 root root   4096 Mar 22  2014 ..
lrwxrwxrwx 1 root root 14 Oct 14 12:34 libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root 14 Oct 14 12:34 libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 627320 Oct 14 12:34 libGL.so.1.2.0

Alternative 'glx':
glx - auto mode
  link currently points to /usr/lib/nvidia
/usr/lib/mesa-diverted - priority 5
  slave glx--libGL.so.1-i386-linux-gnu: 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
/usr/lib/nvidia - priority 100
  slave glx--libGL.so.1-i386-linux-gnu: 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
  slave glx--libnvidia-cfg.so.1-i386-linux-gnu: 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave glx--libnvidia-cfg.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave glx--linux-libglx.so: /usr/lib/nvidia/libglx.so
  slave glx--nvidia-blacklists-nouveau.conf: 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh
  slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so
Current 'best' version is '/usr/lib/nvidia'.

lrwxrwxrwx 1 root root 15 Oct  7 23:36 /etc/alternatives/glx -> /usr/lib/nvidia
lrwxrwxrwx 1 root root 48 Mar 22  2014 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 41 Oct  7 23:36 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 43 Oct  7 23:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrw

Bug#765578: PATH_MAX

[Rémi Denis-Courmont]

Le 2014-10-17 11:41, Salvo Tomaselli a écrit :

The bug isn't in hurd, so I suspect they will never "fix" it.


The src/posix/thread.c patch snippet is a GNU/Hurd bug.

So wontfix.

--
Rémi Denis-Courmont


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

Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Rémi Denis-Courmont]

Le jeudi 16 octobre 2014, 18:25:45 Uwe L. Korn a écrit :
> This suggests that during the packaging process the plugins are modified
> after the cache was generated. I would suspect that in Debian the
> problem is the same too.

I think everybody more-or-less agrees that it would be better (albeit not 
perfect) to generate the plugins cache in some dpkg post-installation script.

I find the title of the bug report misleading though.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#765474: vlc does not play movie dvd in jessie

[Rémi Denis-Courmont]

Le mercredi 15 octobre 2014, 15:23:32 eero a écrit :
> VLC gives black screen and time count stays at 0 when the user start playing
> movie dvd.

DVD menu or DVD playback? In the earlier case, that´s probably VLC Trac bug 
11410 which is already fixed in version 2.2.0~pre4.

Br,

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#761165: vlc: segmentation fault with VDPAU

[Rémi Denis-Courmont]

Le jeudi 11 septembre 2014, 23:51:14 Arthur Marsh a écrit :
> $ gdb --args vlc *VOB

The VLC part of the stack frame is evidently corrupt in this report, e.g. 
'state' is obviously garbage:

> #13 0x7fffc2875f85 in RenderRegion (reg=,
> subpic=, target=, vd=)
> at display.c:197
> sys = 0x7fffbc001b60
> area = {x0 = 810959958, y0 = 720, x1 = 576, y1 = 0}
> color = {red = 0, green = 1.00893489e-42, blue = 8.07147915e-43,
>   alpha = 0}
> surface = 3
> data = 0x7fffbc021340
> state = {struct_version = 64, blend_factor_source_color = 45,
>   blend_factor_destination_color = 615553280,
>   blend_factor_source_alpha = 1773957828,
>   blend_factor_destination_alpha =
> VDP_OUTPUT_SURFACE_RENDER_BLEND_FACTOR_ZERO, blend_equation_color =
> VDP_OUTPUT_SURFACE_RENDER_BLEND_EQUATION_SUBTRACT, blend_equation_alpha =
> 3154174792, blend_constant = {red = 4.59163468e-41, green =
> -2.46105191e+12, blue = 4.59163468e-41,
> alpha = -0.00788353384}}
> pic = 0xfa79e3a8
> pitch = 832

I have no problems playing DVD MPEG2 Video with the same VLC version here, but 
it's a different VDPAU driver.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#761165: vlc: segmentation fault with VDPAU

[Rémi Denis-Courmont]

tags 761165 + moreinfo
thanks

   Hello,

Le 2014-09-11 13:11, Arthur Marsh a écrit :

[7fffbc001268] vdpau_display vout display error: bitmap surface
creation failure: The size of a supplied object does not match the
object it is being used with.  For example, a VdpVideoMixer is
configured to process VdpVideoSurface objects of a specific size.
If presented with a VdpVideoSurface of a different size, this error
will be raised.


That's VdpBitmapSurfaceCreate() failing with error 
VDP_STATUS_INVALID_SIZE. Consequently, OSD and subtitles will fail.


That error does not make much sense in this context; this is probably a 
bug in the VDPAU driver.



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc2200700 (LWP 4213)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x7fffc7191df7 in pipe_sampler_view_reference (view=0x0,
ptr=)
at ../../../../../src/gallium/auxiliary/util/u_inlines.h:151
#2  destroy_video_buffer_private (private=0x7fffcc01acc0)
at 
../../../../../src/gallium/auxiliary/vl/vl_mpeg12_decoder.c:103

#3  0x7fffc71ada58 in vl_video_buffer_set_associated_data (
destroy_associated_data=0x0, associated_data=0x0, vcodec=0x0,
vbuf=0x7fffcc01d560)
at ../../../../../src/gallium/auxiliary/vl/vl_video_buffer.c:200
#4  vl_video_buffer_destroy (buffer=0x7fffcc01d560)
at ../../../../../src/gallium/auxiliary/vl/vl_video_buffer.c:265
#5  0x7fffc71f76ba in vlVdpVideoSurfaceDestroy (surface=5)
at 
../../../../../../src/gallium/state_trackers/vdpau/surface.c:139


That too looks a lot like (another but possibly related) bug in the 
VDPAU driver.


If you can, try to play the same DVD with another graphic card and a 
different VDPAU driver (e.g. the NVIDIA proprietary blob). Otherwise I 
will need a legal sample file. If that is also not possible, I will have 
to assume this is a Mesa driver bug and advise Debian Multimedia to 
reassign.


--
Rémi Denis-Courmont


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

Bug#759818: vlc: VDPAU output - can see video in xterm and icons

[Rémi Denis-Courmont]

tags 759818 + fixed-upstream confirmed
tags 759818 - moreinfo
thanks

Le dimanche 31 août 2014, 13:32:05 Dmitrii a écrit :
> Package: vlc
> Version: 2.2.0~pre2-4
> Followup-For: Bug #759818
> 
> 
> Dear Maintainer,
> Good day!
> 
> The patch works, now every black space is black! Thank you!

OK, thank you for your time.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#760043: weston-terminal: exits under load

[Rémi Denis-Courmont]

Package: weston
Version: 1.5.0-2
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,

When the Weston terminal outputs really fast, it pseudo-randomly ends
up vanishing and the process exits. For me, this is reproducible about
every third time running "ls -lR /". 

On the console that started the compositor:

[11:54:52.890] launching '/usr/lib/weston/weston-desktop-shell'



Error sending request: Resource temporarily unavailable
child 7795 exited

>From a quick investigation, this appears to be an unhandled error
without the libwayland-client marshaller. I guess that write congestion
on the socket to the compositor is not handled; if that is the case,
it is somewhat surprisingly and disturbingly naive.

Feel free to reassign to wayland.

Best regards,

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

Kernel: Linux 3.16.0-basile (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

Versions of packages weston depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.19-10
ii  libcairo2   1.12.16-3
ii  libcolord2  1.2.1-1
ii  libdbus-1-3 1.8.6-2
ii  libdrm2 2.4.56-1
ii  libegl1-mesa10.2.6-1
ii  libegl1-mesa-drivers10.2.6-1
ii  libgbm1 10.2.6-1
ii  libgl1-mesa-glx [libgl1]10.2.6-1
ii  libgles2-mesa   10.2.6-1
ii  libglib2.0-02.40.0-5
ii  libglu1-mesa [libglu1]  9.0.0-2
ii  libinput0   0.2.0-2
ii  libjpeg88d1-1
ii  liblcms2-2  2.6-3
ii  libmtdev1   1.1.5-1
ii  libpam0g1.1.8-3.1
ii  libpango-1.0-0  1.36.6-1
ii  libpangocairo-1.0-0 1.36.6-1
ii  libpixman-1-0   0.32.6-3
ii  libpng12-0  1.2.50-2
ii  libsystemd-login0   208-8
ii  libudev1208-8
ii  libwayland-client0  1.5.0-1
ii  libwayland-cursor0  1.5.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  10.2.6-1
ii  libwayland-server0  1.5.0-1
ii  libx11-62:1.6.2-3
ii  libx11-xcb1 2:1.6.2-3
ii  libxcb-composite0   1.10-3
ii  libxcb-render0  1.10-3
ii  libxcb-shape0   1.10-3
ii  libxcb-shm0 1.10-3
ii  libxcb-xfixes0  1.10-3
ii  libxcb-xkb1 1.10-3
ii  libxcb1 1.10-3
ii  libxcursor1 1:1.1.14-1
ii  libxkbcommon0   0.4.1-2

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

weston 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#758582: vlc: Vlc segfaults at the end of video reproduction when video acceleration VAAPI is selected

[Rémi Denis-Courmont]

reassign 758582 libavcodec55
affects 758582 vlc
thanks


Le dimanche 31 août 2014, 10:54:20 Marco Mattiolo a écrit :
> #0  Release (p_external=, p_ff=) at
> avcodec/vaapi.c:519
> #1  0x7fffc671eadb in vlc_va_Release (frame=0x7fffc0153348,
> va=)
>  at avcodec/va.h:56
> #2  ffmpeg_ReleaseFrameBuf (p_context=,
> p_ff_pic=0x7fffc0153348)
>  at avcodec/video.c:1079
(...)
> #10 0x7fffc5b7f37b in ff_thread_free (avctx=avctx@entry=0x7fffbcc43d40)
>  at /build/libav-EKDVFO/libav-10.4/libavcodec/pthread.c:85
> #11 0x7fffc5896cd0 in avcodec_close (avctx=0x7fffbcc43d40)
>  at /build/libav-EKDVFO/libav-10.4/libavcodec/utils.c:1609

Hmm, yeah. libavcodec releases the VA buffers in avcodec_close() when it is 
supposed to do that in the earlier avcodec_flush_buffers(). This causes a use-
after-free and crash in VLC.

Reassigning.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#758582: vlc: Vlc segfaults at the end of video reproduction when video acceleration VAAPI is selected

[Rémi Denis-Courmont]

tags 758582 + moreinfo
thanks

Le mardi 19 août 2014 00:39:10, vous avez écrit :
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffd06b5700 (LWP 2772)]
> Release (p_external=, p_ff=) at
> avcodec/vaapi.c:519
> 519 avcodec/vaapi.c: File o directory non esistente.
> (gdb)

This looks like a well-known bug in libavcodec. Please provide the whole stack 
trace.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#759818: vlc: VDPAU output - can see video in xterm and icons

[Rémi Denis-Courmont]

Le samedi 30 août 2014, 20:24:13 Dmitrii a écrit :
> After today update
> [apt log
> Start-Date: 2014-08-30  15:53:09
> Install:  libvlccore8:amd64 (2.2.0~pre2-4, automatic),
> Upgrade:  vlc-plugin-notify:amd64 (2.1.5-1, 2.2.0~pre2-4), vlc-nox:amd64
> (2.1.5-1, 2.2.0~pre2-4), vlc-data:amd64 (2.1.5-1, 2.2.0~pre2-4),
> libvlc5:amd64 (2.1.5-1, 2.2.0~pre2-4)
> Remove: libvlccore7:amd64 (2.1.5-1), libdirac-decoder0:amd64 (1.0.2-7), vlc-
> plugin-pulse:amd64 (2.1.5-1)
> End-Date: 2014-08-30  16:01:09]
> I can see video, using VDPAU as output in window borders(xfce), xterm, and
> Thunar icon labels on other workspaces
> If using X11 XCB uotput it is allright.
> 
> Sorry for my English,
> Best regards, Dmitrii

I can't reproduce it here. Does the patch below help? Does it affect other 
applications using VDPAU?

diff --git a/modules/hw/vdpau/display.c b/modules/hw/vdpau/display.c
index 54e1cb8..e64fc5e 100644
--- a/modules/hw/vdpau/display.c
+++ b/modules/hw/vdpau/display.c
@@ -662,9 +662,6 @@ static int Open(vlc_object_t *obj)
 goto error;
 }
 
-VdpColor black = { 0.f, 0.f, 0.f, 1.f };
-vdp_presentation_queue_set_background_color(sys->vdp, sys->queue, 
&black);
-
 sys->cursor = XCB_cursor_Create(sys->conn, screen);
 sys->pool = NULL;
 
-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Rémi Denis-Courmont]

Le 2014-08-22 17:02, Fabian Greffrath a écrit :
However, I think it would be a good idea to add plugin cache 
generation

as an additional test during build phase. How about that?


Unless Debian has pro-actively patched it out of the upstream build 
system, it's already being done.


--
Rémi Denis-Courmont


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

Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Rémi Denis-Courmont]

Le 2014-08-22 11:24, Harald Sitter a écrit :
On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont 
 wrote:

Le 2014-08-22 10:31, Harald Sitter a écrit :


All that being said perhaps the more interesting bit is why exactly
VLC thinks the cache is invalid to begin with. In particular
considering we only have one build that builds with all plugins we
have packaged and there are no third party plugins in any package
anywhere ever. So the cache should always have a superset of what 
is

available on a system.



Changed file name, file size, or file modification time.


But how could either of those happen if the only supplier of plugins
are the VLC packages and so all of the cases you mentioned should be
reflected in a new cache file provided by a new version of vlc-nox?


You tell me; I have never reproduced the alleged crash.

Or more to the point... how could a completely new installation with 
a

matching version of vlc-nox and vlc end up thinking the cache is
invalid?


It can't, unless something mucks with the modification time or some 
data corruption happens.


I think installation aborting if the cache generation actually 
doesn't

work because of ABI breakage or whatever in an underlying library
seems like a very appropriate course of action given that all libvlc
applications would potentially end up broken at that point. It's not
the libvlc applications that are broken, so willingly letting them
crash rather than making sure we end up with a working set of plugins
+ cache seems ill-advised at best. Alas, this can be argued back and
forth, it sounds like a less than optimal situation to begin with.


For a dedicated installer, I would agree that failing to install 
straight up is better than failing to run later.


But we are talking about the Debian packaging system here. Failing to 
install means screwing up the whole oeprating system.


--
Rémi Denis-Courmont


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

Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Rémi Denis-Courmont]

Le 2014-08-22 10:31, Harald Sitter a écrit :

All that being said perhaps the more interesting bit is why exactly
VLC thinks the cache is invalid to begin with. In particular
considering we only have one build that builds with all plugins we
have packaged and there are no third party plugins in any package
anywhere ever. So the cache should always have a superset of what is
available on a system.


Changed file name, file size, or file modification time.


I fail to see how exactly the additions could make the maintainer
scripts fail to be honest, other than having a broken cache-gen 
which

surely is the sign of a much deeper problem that should not have
gotten beyond build time to begin with.



Experience has shown that changes to certain libraries causes the 
cache
generation to crash, and the maintainers of those libraries do not 
test
against VLC before uploading to Debian. I mean glib, gobject, Qt, 
GL, libav

to name the obvious ones...


How does that work? Wouldn't that also defunct the plugins 
themselves?


VLC would probably crash too, but a crashing program is not as bad and 
as likely to be reported as a crashing installation procedure.


--
Rémi Denis-Courmont


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

Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Rémi Denis-Courmont]

Le 2014-08-22 08:25, Harald Sitter a écrit :
That is one good reason to generate the cache at build time, where 
any problem
can be detected early on. Crashing during dpkg postinst script is 
much worse.


|| true?


Then there will be no cache, and you are not solving the problem you 
want to solve.



I fail to see how exactly the additions could make the maintainer
scripts fail to be honest, other than having a broken cache-gen which
surely is the sign of a much deeper problem that should not have
gotten beyond build time to begin with.


Experience has shown that changes to certain libraries causes the cache 
generation to crash, and the maintainers of those libraries do not test 
against VLC before uploading to Debian. I mean glib, gobject, Qt, GL, 
libav to name the obvious ones...


--
Rémi Denis-Courmont


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

Bug#755154: vlc cache gen should happen at runtime, not buildtime

[Rémi Denis-Courmont]

Hello,

Le vendredi 18 juillet 2014, 12:52:32 Harald Sitter a écrit :
> since vlc plugins are spread across multiple packages the plugin cache
> generated at buildtime is almost always wrong

As long as Debian does not ship any unofficial native VLC plugin, the 
build-time 
cache will not lack any entry.

> which makes vlc load all plugins at runtime

No. VLC only loads plugins that are absent or mismatched in the cache. As long 
as the cache contains a superset of what is actually installed, VLC will not 
attempt to load anything unnecessary.

> which in turn can result in runtime symbol clashes

That is one good reason to generate the cache at build time, where any problem 
can be detected early on. Crashing during dpkg postinst script is much worse.

> when it loads the qt4 gui in a qt5 libvlc application for example.
 
That will happen only if Qt4 is not in the plugins cache. If you install the 
plugins cache from a build with Qt4, it should be in.

> attached you should fine a patch which resolves this problem by
> a) not installing the buildtime cache
> b) fully implementing trigger capability by having postinst refresh the
> cache c) have prerm drop the runtime cache so the dirs can be cleaned up
> properly by dpkg

I am afraid this will create more problems than it will solve. With this 
patch, there is a very real possibility that the package installation will 
fail.

IMNSHO, the proper fix consists of disabling non-cached plugins support, 
especially for LibVLC applications other than VLC proper. That is doable, but 
not completely straightforward.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#745556: Closing dialog for allowing invalid SSL certificate causes default to be accepted

[Rémi Denis-Courmont]

Le 2014-06-23 20:38, Jim Scadden a écrit :
Rémi, please could you advise if you would still like the behaviour 
to
be modified? If so, given that the user has already stated on the 
first
dialog box that they wish to connect to the server, and closing the 
2nd

dialog causes the certificate to only be accepted for the current
session, would you be happy for this bug to be tagged as 'wishlist'
since this is something could potentially require a substantial 
change

upstream?


I am not sure I see the wisdom in tagging a security problem as 
wishlist. "Current session" is more than enough for a MITM to the steal 
the IMAP or POP credentials and hijack the account. And in this case, it 
seems there is hardly any way out for the user: Except for xkill, I 
cannot think of any way to reject an untrusted connection here.


I'd argue the security team is in a better position than me to 
determine what to do though.


--
Rémi Denis-Courmont


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

Bug#748971: vlc crashes when trying to open "preferences" or trying to display the playing list

[Rémi Denis-Courmont]

tags 748971 + moreinfo
thanks

Le 2014-06-08 01:42, Ilario Gelmetti a écrit :

Opening vlc using
 gdb vlc
and then "run" results in a prefectly working vlc.


Then save the core dump of the segmentation fault without gdb, and then 
open the core dump with gdb.


With so few infos, there is nothing we can do.

--
Rémi Denis-Courmont


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

Bug#751940: update

[Rémi Denis-Courmont]

Le 2014-06-18 14:28, Henri Salo a écrit :
Do you have any more information about this? It is quite hard to fix 
security

vulnerability without any details.


The Mozilla foundation writes code for an alternate reality where the 
version number of the VLC NPAPI plugin and the (Lib)VLC run-time have 
identical version numbers. Indeed (Lib)VLC version 2.0.0 has security 
issues. But that says nothing of version 2.0.0 of the VLC NPAPI plugin.


In other words, the bug lies within the version checks of the Mozilla 
browser.


--
Rémi Denis-Courmont


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

Bug#697121: vlc: sudden very loud sound to cause hearing demage

[Rémi Denis-Courmont]

Le lundi 9 juin 2014, 15:56:44 Felipe Sateler a écrit :
> But isn't an uncorked stream an "inactive stream"? I'm not sure of
> what you mean by that.

I never wrote anything about inactive streams. Inactive sessions is a WASAPI 
notion, that the -in that respect inferior- PulseAudio design lacks.

> >> 2. VLC could create the stream on startup and destroy it on exit. This
> >> is what Clementine seems to do.
> > 
> > That is not possible since VLC may play different formats at successive
> > times. Also...
> 
> OK. So that rules out permanent streams. BTW, out of curiosity, why is
> this the case? I thought VLC did their own decoding (and thus output a
> single stream format).

VLC decodes (and PulseAudio does not) but the sample rates and channels maps 
may vary, not to mention pass-through.

> Also, semi-permanent streams might be the option then: reuse streams
> as long as the format doesn't change. This may well be more work than
> this problem merits, though.
> 
> >> 3. VLC could, at startup, create a stream, get the volume and destroy
> >> the stream.
> > 
> > Because of flat volumes, doing that would potentially cause spurious
> > changes to the master volume and glitches in mixer UIs.
> 
> Is this really correct? If pa_stream_connect_playback is set with a
> NULL cvolume parameter, PA should set a reasonable volume for the
> stream.

Yes, and...?

> > Furthermore, all options 1 and 2 fail if another process creates a stream
> > with the same role (or whatever matching criteria) in the mean time, and
> > change the volume.
> 
> I don't think roles are used for this purpose. Streams have
> independent volumes, AFAICT.

Active streams have independent volumes. But the whole point is what to do 
without an active stream. By *default*, PulseAudio restores volumes by stream 
role.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#697121: vlc: sudden very loud sound to cause hearing demage

[Rémi Denis-Courmont]

Le lundi 9 juin 2014, 14:51:53 Felipe Sateler a écrit :
> OK, thanks for explaining. I see that vlc creates the stream when it
> starts playback and destroys it when stopped (although not pause).
> 
> This leaves the following options:
> 
> 1. Pulseaudio could add a function to get the volume an output/input
> sink/source stream would get if it were created.

PulseAudio does not really have a notion of inactive session, as Windows 
does... I don't really see how that would work with the current architecture 
(not that I'm that familiar with it though).

> 2. VLC could create the stream on startup and destroy it on exit. This
> is what Clementine seems to do.

That is not possible since VLC may play different formats at successive times. 
Also...

> 3. VLC could, at startup, create a stream, get the volume and destroy
> the stream.

Because of flat volumes, doing that would potentially cause spurious changes to 
the master volume and glitches in mixer UIs.

Furthermore, all options 1 and 2 fail if another process creates a stream with 
the same role (or whatever matching criteria) in the mean time, and change the 
volume.

> Are there problems with going with option 2? This option has the added
> benefit the volume can potentially be controlled by another program
> before starting playback.

Ultimately, the problem is simple. On the one hand, PulseAudio developers 
consider that audio applications shall not show volume UI. Only the dedicated 
mixer application(s) and the session process grabbing the volume media keys 
shall be concerned with the volume. On the other hand, VLC GUI developers want 
to have a volume control.

The two perspectives are incompatible. That is not a technical problem; and 
thus it won't be solved by code.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#750995: does this bug affect wheezy too?

[Rémi Denis-Courmont]

Le 2014-06-09 19:14, Holger Levsen a écrit :
does this bug ("Cannot reject invalid SSL certificate for IMAP server 
as

dialog keeps appearing") affect wheezy too? Or is that jessie only?


TBH, I don't know; I don't have a Wheezy install handy.

--
Rémi Denis-Courmont


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

Bug#697121: vlc: sudden very loud sound to cause hearing demage

[Rémi Denis-Courmont]

Le vendredi 6 juin 2014, 19:32:30 Felipe Sateler a écrit :
> > Unfortunately, VLC cannot get the PulseAudio volume until after audio
> > playback starts. There is no way to fix this on VLC side: there is no API
> > in libpulse to get the volume of an application until after a sink
> > input/stream is created.
> What about pa_context_get_sink_info_by_name? With that you can get the
> volume of the default sink by specifying NULL as the sink name.

That will only work the first time you use a media player ever. Afterward, 
PulseAudio will remember a volume for the media player role, that is distinct 
from the default sink volume - with default settings.

In other words, this does not work.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#699832: vlc-nox: document VLC_PLUGIN_PATH environment variable

[Rémi Denis-Courmont]

tags 699832 + fixed-upstream
thanks

This is fixed in VLC 2.2.0.

--
Rémi Denis-Courmont


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

Bug#748794: vlc: Segmentation fault when browsing filesystem at ~/Music

[Rémi Denis-Courmont]

reassign 748794 libdvdnav4
thanks

Hello,

libdvdnav checks if the directory is a DVD disk, and crashes.

This is probably already fixed in newer libdvdnav versions.

Le 2014-05-21 03:50, Lauri Kaila a écrit :

Package: vlc
Version: 2.0.3-5
Severity: important

Dear Maintainer,

My VLC player crashes sometimes when browsing the filesystem for my 
mp3s

Playlist->My Computer->My Music->[some directory]

The crash occurs when I click a directory name, which I think 
performs

a scan for the directory contents (when crash doesn't happen, it'll
create an arrow for expansion).

backtrace:

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/vlc...Reading symbols from
/usr/lib/debug/usr/bin/vlc...done.
done.
(gdb) r
Starting program: /usr/bin/vlc
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

VLC media player 2.0.3 Twoflower (revision 2.0.2-93-g77aa89e)
[New Thread 0x7fffedce8700 (LWP 15726)]
[0x605108] main libvlc: Running vlc with the default interface. Use
'cvlc' to use vlc without interface.
[New Thread 0x7fffec992700 (LWP 15727)]
[New Thread 0x7fffddcf1700 (LWP 15728)]
libdvdnav: Using dvdnav version 4.2.0
libdvdread: Encrypted DVD support unavailable.

****
**  No css library available. See **
**  /usr/share/doc/libdvdread4/README.css **
**  for more information. **
****


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffddcf1700 (LWP 15728)]
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
32  ../sysdeps/x86_64/multiarch/../strlen.S: No such file or 
directory.

(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
#1  0x7fffed5b2f07 in DVDOpen () from
/usr/lib/x86_64-linux-gnu/libdvdread.so.4
#2  0x7fffed7d7ff8 in ?? () from 
/usr/lib/x86_64-linux-gnu/libdvdnav.so.4

#3  0x7fffed7d0a75 in dvdnav_open () from
/usr/lib/x86_64-linux-gnu/libdvdnav.so.4
#4  0x7fffedcedd3a in Open (p_this=0xbbfed8) at dvdnav.c:231
#5  0x7795fc29 in vlc_module_load 
(p_this=p_this@entry=0xbbfed8,

psz_capability=psz_capability@entry=0x77999012
"access_demux", psz_name=,
b_strict=b_strict@entry=true, probe=probe@entry=0x7795f4d0
) at modules/modules.c:347
#6  0x779600b4 in module_need (obj=obj@entry=0xbbfed8,
cap=cap@entry=0x77999012 "access_demux",
name=, strict=strict@entry=true) at 
modules/modules.c:437

#7  0x7791d7e8 in demux_New (p_obj=p_obj@entry=0xb99ab8,
p_parent_input=p_parent_input@entry=0xb99ab8,
psz_access=0xbbfe00 "file",
psz_demux=psz_demux@entry=0x779a188a "", psz_location=0xbbfe07
"/home/late/Music",
s=s@entry=0x0, out=0xa6ab00, b_quick=b_quick@entry=false) at
input/demux.c:195
#8  0x7792a281 in InputSourceInit
(p_input=p_input@entry=0xb99ab8, in=0xbaf0c0,
psz_mrl=0xc0ed70 "file:///home/late/Music",
psz_forced_demux=psz_forced_demux@entry=0x0,
b_in_can_fail=b_in_can_fail@entry=false) at input/input.c:2400
#9  0x7792b24e in Init (p_input=p_input@entry=0xb99ab8) at
input/input.c:1258
#10 0x7792ea4d in input_Read
(p_parent=p_parent@entry=0xb54288, p_item=p_item@entry=0xba74c0) at
input/input.c:175
#11 0x7fffdf03523c in Run (data=0xb54288) at mediadirs.c:208
#12 0x776c2b50 in start_thread (arg=) at
pthread_create.c:304
#13 0x76a6a0ed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14 0x in ?? ()
(gdb)


--
Rémi Denis-Courmont


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

Bug#745352: gdb details

[Rémi Denis-Courmont]

reassign 745352 libtar0
found 745352 1.2.20-3
notfound 745352 1.2.16-1+deb7u2
thanks

Hello,

Le samedi 3 mai 2014, 14:44:08 Pierre Edouard FABRE a écrit :
> Package: vlc
> Version: 2.1.2-2+b3
> Followup-For: Bug #745352

> Dear maintainers,
> Please find dmesg and gdb details:
> -- dmesgvlc[9156]: segfault at 8 ip 7f2947455c7a sp 7f293ca6f918
> error 4 in libc-2.18.so[7f29473d4000+1a]

This appears to be caused by newer versions of libtar. There is a NULL 
dereference in-there. Downgrading libtar0 from Jessy to Wheezy "solves" the 
problem.

I don't know if this has security implications.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#745784: vlc: segmentation fault when plaking .mkv file

[Rémi Denis-Courmont]

Le 2014-04-25 15:27, Reinhard Tartler a écrit :
On Fri, Apr 25, 2014 at 4:02 AM, Rémi Denis-Courmont 
 wrote:

reassign 745784 libavcodec54
tags 745784 + fixed-upstream
thanks

   Hello,

This is a known bug in libav 9 and already fixed upstream.


Remi,

Can you a bit elaborate on this bug? Is it fixed in Libav10?


I think so. You'll need to ask Anton for further details.

--
Rémi Denis-Courmont


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

Bug#745784: vlc: segmentation fault when plaking .mkv file

[Rémi Denis-Courmont]

reassign 745784 libavcodec54
tags 745784 + fixed-upstream
thanks

   Hello,

This is a known bug in libav 9 and already fixed upstream.

Le 2014-04-25 06:26, Arthur Marsh a écrit :

Package: vlc
Version: 2.1.2-2+b3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd8135700 (LWP 20767)]
__memcpy_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:37
37  ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such
file or directory.
(gdb) bt
#0  __memcpy_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:37
#1  0x7fffc9fa240e in memcpy (__len=1280, __src=0x0,
__dest=) at
/usr/include/x86_64-linux-gnu/bits/string3.h:51
#2  ffmpeg_CopyPicture (p_ff_pic=0x7fffd0c39f00, 
p_pic=0x7fffb800c510,

p_dec=0x7fffd0c0b3e8) at avcodec/video.c:897


--
Rémi Denis-Courmont


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

Bug#745556: kmail accepts invalid SMTP TLS certificate against user action

[Rémi Denis-Courmont]

Le 2014-04-24 08:53, Yves-Alexis Perez a écrit :

On Tue, Apr 22, 2014 at 10:33:28PM +0300, Rémi Denis-Courmont wrote:
The "cancel" button has no effects other than to bring the same 
dialog

almost instantly back in an infinite loop.


Are you sure the loop is infinite and kmail is not just checking 
folder
after folder? (not that it wouldn't be a bad idea to cache the 
decision

for the user/host/port triplet).


I do not know why it seems to loop. I set a refresh delay of 5 minutes, 
but the dialog comes back within less than a second, again and again...


--
Rémi Denis-Courmont


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

Bug#743997: vlc: "Start time" cannot exceed 23 hours

[Rémi Denis-Courmont]

forwarded https://trac.videolan.org/vlc/ticket/4503
tags 743997 + upstream confirmed
thanks


Le mardi 8 avril 2014 19:55:41, vous avez écrit :
> Package: vlc
> Version: 2.1.2-2+b3
> Severity: wishlist
> 
> VLC cannot be told to begin playback at more than 23:59:59 hours into
> an audio file. Extending this to a day and beyond would assist users
> listening to extremely long pieces of music, such as those released by
> free culture band Bull of Heaven.

That's a limitation of the QTimeEdit widget from QtGui. Don't hold your breath 
for a resolution on VLC side...

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#745556: kmail accepts invalid SMTP TLS certificate against user action

[Rémi Denis-Courmont]

Package: kmail
Version: 4:4.11.5-1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

Configure an outgoing SMTP server with (Start)TLS in kmail. If the
server presents an invalid or self-signed certificate to the agent,
KDE will show a warning dialog offering three choices: details,
continue and cancel (not sure about translation from fr_FR locale).

The "details" button works as expected, showing certificate infos,
then returning to the previous dialog.

The "cancel" button has no effects other than to bring the same dialog
almost instantly back in an infinite loop. 

The "continue" button yields another dialog letting the user choose how
long to accept the certificate, either forever, or only for the current
session. If the dialog is closed without answer, Kmail assumes forever.
At that point, the mail feeder will happily send user credentials over
to the untrusted server.


So basically, there are no ways to reject an invalid certificate, other
than to kill the mail feeder or take the system offline.




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

Kernel: Linux 3.13.10-basile (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

Versions of packages kmail depends on:
ii  kde-runtime   4:4.11.5-1
ii  kdepim-runtime4:4.11.5-1
ii  kdepimlibs-kio-plugins4:4.11.5-4+b1
ii  libakonadi-calendar4  4:4.11.5-4+b1
ii  libakonadi-contact4   4:4.11.5-4+b1
ii  libakonadi-kde4   4:4.11.5-4+b1
ii  libakonadi-kmime4 4:4.11.5-4+b1
ii  libakonadiprotocolinternals1  1.11.0-1
ii  libc6 2.18-4
ii  libcalendarsupport4   4:4.11.5-1
ii  libgcc1   1:4.9-20140411-2
ii  libgpgme++2   4:4.11.5-4+b1
ii  libgrantlee-core0 0.3.0-5
ii  libincidenceeditorsng44:4.11.5-1
ii  libkabc4  4:4.11.5-4+b1
ii  libkalarmcal2 4:4.11.5-4+b1
ii  libkcalcore4  4:4.11.5-4+b1
ii  libkcalutils4 4:4.11.5-4+b1
ii  libkcmutils4  4:4.11.5-3
ii  libkdecore5   4:4.11.5-3
ii  libkdepim44:4.11.5-1
ii  libkdeui5 4:4.11.5-3
ii  libkio5   4:4.11.5-3
ii  libkleo4  4:4.11.5-1
ii  libkmime4 4:4.11.5-4+b1
ii  libknewstuff3-4   4:4.11.5-3
ii  libknotifyconfig4 4:4.11.5-3
ii  libkontactinterface4  4:4.11.5-4+b1
ii  libkparts44:4.11.5-3
ii  libkpgp4  4:4.11.5-1
ii  libkpimidentities44:4.11.5-4+b1
ii  libkpimtextedit4  4:4.11.5-4+b1
ii  libkpimutils4 4:4.11.5-4+b1
ii  libkprintutils4   4:4.11.5-3
ii  libksieveui4  4:4.11.5-1
ii  libktnef4 4:4.11.5-4+b1
ii  libmailcommon44:4.11.5-1
ii  libmailimporter4  4:4.11.5-1
ii  libmailtransport4 4:4.11.5-4+b1
ii  libmessagecomposer4   4:4.11.5-1
ii  libmessagecore4   4:4.11.5-1
ii  libmessagelist4   4:4.11.5-1
ii  libmessageviewer4 4:4.11.5-1
ii  libnepomukcore4   4:4.11.5-2+b1
ii  libpimcommon4 4:4.11.5-1
ii  libqt4-dbus   4:4.8.5+git242-g0315971+dfsg-2
ii  libqt4-network4:4.8.5+git242-g0315971+dfsg-2
ii  libqt4-xml4:4.8.5+git242-g0315971+dfsg-2
ii  libqtcore44:4.8.5+git242-g0315971+dfsg-2
ii  libqtgui4 4:4.8.5+git242-g0315971+dfsg-2
ii  libqtwebkit4  2.2.1-7
ii  libsendlater4 4:4.11.5-1
ii  libsolid4 4:4.11.5-3
ii  libsoprano4   2.9.4+dfsg-1
ii  libstdc++64.9-20140411-2
ii  libtemplateparser44:4.11.5-1
ii  perl  5.18.2-2+b1

Versions of packages kmail recommends:
ii  gnupg-agent  2.0.22-3
ii  gnupg2   2.0.22-3
ii  pinentry-qt4 [pinentry-x11]  0.8.3-2

Versions of packages kmail suggests:
pn  clamav | f-prot-installer
pn  kaddressbook 
pn  kleopatra
pn  procmail 
pn  spamassassin | bogofilter | annoyance-filter | spambayes | bsfilter  

-- 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#658254: rdnssd does not support DNSSL

[Rémi Denis-Courmont]

   Hello,



> Upstream is a 1.0.3, and has this bug fixed.  Debian is still

> on 1.0.1 (from three years ago!) even in Sid.



I know; I am upstream. But unfortunately I never find time to update the

package and I lack an upload sponsor. Consequently, I put the package for

adoption a while already, and requested help yet earlier.



> Can we have a new version, please?



It would really help if someone with time and upload privileges would

adopt it.



-- 

Rémi Denis-Courmont


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

Bug#741240: vlc segfaults while playing MKV files

[Rémi Denis-Courmont]

reassign 741240 libavcodec54
thanks

Hello,

This appears to be a race condition in libavcodec threaded decoding. It should 
be fixed in newer upstream libavcodec versions already. In the mean time, you 
might have to disable threaded decoding in the VLC preferences.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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

Bug#403359: vlc: Ogg muxing crashes on PowerPC

[Rémi Denis-Courmont]

tags 403359 + moreinfo
thanks

Hello,

This was filed against an ancient version. Does the problem still exist? If so, 
can you please provide a stack trace from gdb?

Regards,

-- 
Rémi Denis-Courmont
http://www.remlab.net/


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