t dependency.
On Wed, Sep 04, 2024 at 08:13:52PM +, js jb wrote:
> After upgrading libnss3, the debian firefox_130.0-1 runs and can access
> remote sites.
> However, some but not all sites with images (for example
> http://www.reuters.com) , do NOT display the images, only the te
Tabs running Amazon Prime videos crash constantly, within seconds of opening.
This was fixed by copying the firefox executable downloaded from Mozilla to
/usr/lib/firefox/firefox;previously it was necessary to copy also the shared
libraries that came from mozilla to /usr/lib/x86_64-linux-gnu,wher
After upgrading libnss3, the debian firefox_130.0-1 runs and can access remote
sites.
However, some but not all sites with images (for example
http://www.reuters.com) , do NOT display the images, only the text.This was
fixed by copying the libraries from the direct mozilla download in
firefox/
The problem is resolved by upgrading libnss3 to version 2:3.103-1, which
includes the libfreeblpriv3.so library
Previous versions of firefox depended on the latest version of libnss3 but
130.0-1 does not.
Upgrading libnss3 fixes this problem with firefox 130.0-1
I found that by only setting LD_LIBRARY_PATH to include the firefox directory
in the Mozilla direct download,the debian packaged firefox_130.0-1 works as
expected.
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 over
hanks,--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: li
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
; 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
t 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 package
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 firs
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 w
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) ins
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 is
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, an
20 matches
Mail list logo
