I've noticed that the behavior described in this bug tends to happen in
messages whose attachments were deleted.
thanks
This is the exact version of handbrake I used from fr.handbrake.ghb that fixed
the subtitles issue (which seems caused because the character encoding of the
subtitles is not always recognized):
=> flatpak info fr.handbrake.ghb
HandBrake - Video Transcoder
ID: fr.handbrake.ghb
I've installed the snapshot version of handbrake from handbrake.fr directly
(via flatpak)and verified that on the same DVDs, it generates the subtitles
perfectly.
I also built the debian version of handbrake from source and that one still has
the same problems.One can also see the subtitles
,--jack
On Sunday, February 19, 2023 at 03:03:51 PM EST, Rémi Denis-Courmont
wrote:
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.
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
; sleep 5;
fetchmailWORK: fetchmail -q ; fetchmail
Clarifying this would be useful in the man page or other documentation.
thanks,--jack
On Friday, February 3, 2023 at 10:20:36 AM EST, js jb
wrote:
After upgrading to the new fetchmail 6.4.36-1, the problem has been fixed
without any
After upgrading to the new fetchmail 6.4.36-1, the problem has been fixed
without any change at all to my .fetchmailrc.
This bug can now be closed.
thanks,--jack
ve not received a
better one in a separate message then please contact Florian Schlichting
by
replying to this email.
--
990160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
On Sun, Jul 04, 2021 at 12:02:13AM +, js jb
I should add that making nvidia-driver conflict with later kernel versions for
which it has not been tested is only an *example* solution,but clearly not the
only way to keep apt-get upgrade working properly with nvidia-driver.
A more flexible solution would be to create an optional dummy
Thank you very much Andreas for your quick response and explanation of the
problem.
I was able to install nvidia-driver_440.44-2 on my 4.17 and, after a few days
of testing, expect the upgrade tothe 5.4 kernel will work,.
However, I had some difficulty getting the 440.44-2 driver to work at
This problem is still present with the new nvidia-driver (390.42) and
xserver-xorg (1.7.7+19).
I now believe this is an issue either with the nvidia driver for 32 bit linux
or with xorg rather than xscreensaveras I have found another application,
flightgear, that show exactly the same symptoms
Package: geeqie
Version: 1:1.4-3
Severity: important
Dear Maintainer,
===
I noticed that in a handful of cases (26 jpegs out of 529), the EXIF
information as seen by exiftool was incorrect;the lens type was a list (see
below)
Package: eog
Version: 3.28.0-2
Severity: important
Dear Maintainer,
=
After upgrading to eog 3.28.0-2 I saw it continues to fail when opening 24MP
(6000x4000) JPG files,
although it still works
hello,
In addition to adding the explanation of ESR, could you add an explanation of
the process involved in making a mozilla releaseof firefox into a firefox-esr
package?
Currently the latest firefox-esr in the testing distribution is 52.6.0esr-2
while the latest stable firefox is 58.0.1 and
Thanks,
"BTW, your pinning and sources.list is extreme. That's not really a sensible
thing to do and can cause a lotof trouble. "
If you can be more explicit, I'd very much appreciate the feedback.
As it is, the pinning I use is to prevent unintentional changes to nvidia
drivers, linux kernel,
15 matches
Mail list logo
