Bug#1051796: thunderbird not displaying message headers correctly.

[js jb]

I've noticed that the behavior described in this bug tends to happen in 
messages whose attachments were deleted.
thanks

Bug#1032972: handbrake: debian version of handbrake does NOT handle subtitles correctly

[js jb]

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
 Ref: app/fr.handbrake.ghb/x86_64/stable
    Arch: x86_64
  Branch: stable
 Version: 1.6.1
 License: GPL-2.0+
  Origin: ghb-origin
  Collection: 
Installation: user
   Installed: 123.3 MB
 Runtime: org.gnome.Platform/x86_64/43
 Sdk: org.gnome.Sdk/x86_64/43

  Commit: 227d2a8398a850cd93a6662116c0bc64be187eeb4f2e5a2ae1e490838cd03248
 Subject: Export fr.handbrake.ghb
    Date: 2023-01-23 18:08:28 +

Bug#1032972: handbrake: debian version of handbrake does NOT handle subtitles correctly

[js jb]

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 overlaying each other so that 
in rapid dialog multiple subtitles appearone on top of each other, making them 
all illegible.  This does not happen in the handbrake snaphshot.
thanks,--jack

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

[js jb]

 Thanks,
There was an old version of vdpau-va-driver installed in the system even though 
it's no longer in Debian.
Removing it allowed vlc to work with the 2.17.0-1 libva libraries.
Perhaps this should be moved to the libva bug list with a request to add a 
conflict with vdpau-va-driver?
thanks,--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.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#1031249: VLC 3.0.18 crash FIXED with downgrade of libva2 libraries to 2.14.0-1

[js jb]

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

Bug#1029815: Problem fixed in fetchmail version 6.4.36-1

[js jb]

 After rebooting my computer, with no changes to fetchmailrc or the version of 
fetchmail, I see in syslog:    
2023-02-05T11:15:34.903940-05:00 berkeley fetchmail[4457]: The nodetach option 
is in effect, ignoring logfile option.
The file /usr/lib/systemd/user/fetchmail.service  has a --nodetach option but 
removing it (and restarting the fetchmail service)makes no difference and 
fetchmail still appears running with the --nodetach option in place.
It seems for the logfile to work one must restart fetchmail immediately, 
otherwise the default --nodetach takes effect:FAIL:  fetchmail -q ; 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 change at all to my .fetchmailrc.
This bug can now be closed.
thanks,--jack
  

Bug#1029815: Problem fixed in fetchmail version 6.4.36-1

[js jb]

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

Bug#990160: closed by Florian Schlichting (Re: [Pkg-mpd-maintainers] Bug#990160: mpd: music players using mpd do not play concatenated mp3 files to the end)

[js jb]

 Thank you,
The workaround that worked for me, from the discussion of the bug, was to 
modify  /etc/mpd.conf with this decoder section,using ffmpeg and preventing mad 
and mpg123 from being used.


# Decoder #
#
decoder {
    plugin "ffmpeg"
    enabled "yes"
}

decoder {
    plugin  "hybrid_dsd"
    enabled "no"
#   gapless "no"
}

# disable mad to allow concatenated mp3 to play through to the end:
decoder {
    plugin "mad"
    enabled "no"
}

decoder {
    plugin "mpg123"
    enabled "no"
}



thanks again,--jack

On Saturday, November 26, 2022 at 11:39:05 AM EST, Debian Bug Tracking 
System  wrote:  
 
 This is an automatic notification regarding your Bug report
which was filed against the mpd package:

#990160: mpd: music players using mpd do not play concatenated mp3 files to the 
end

It has been closed by Florian Schlichting .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have 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 wrote:
>  After posting the files to reproduce the problem on github, they posted a 
>work-around for this issue:
> In /etc/mpd.conf, disable the 'mad' decoder with the lines:decoder {
>    plugin "mad"
>    enabled "no"
> }This solved the problem.

I'm closing this bug after reading the upstream discussion (different
decoders behaving differently, observing or ignoring Xing headers
present in the file). If someone has a suggestion how to document the
workaround, that could probably be useful for other users.

FlorianPackage: mpd
Version: 0.22.6-1+b1
Severity: normal

Dear Maintainer,

==

I've noticed that music players that use mpd,like cantata, do not play
concatenated mp3 files to the end but stop after the first part of the
concatenated file.

For example: cat mvmt1.mp3 mvmt2.mp3 mvmt3.mp3 > symph1.mp3
will play only mvmt1.mp3 on an mpd-based player when symph1.mp3 is
played.

This does NOT happen on music players that do not use mpd, like vlc or
elisa (or any android music player).

The only work-around is to use a non-mpd player for this.

Concatenated mp3 files are useful when one wants to create a single mp3 for
a classical piece composed of many movements, as above, and create a
playlist of several of these. Each symphony will then be played
completely but the next symphony to play can be a shuffle choice (but
without shuffling the individual movements within each symphony).

==


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

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

Versions of packages mpd depends on:
ii  adduser                            3.118
ii  init-system-helpers                1.60
ii  libadplug-2.3.3-0                  2.3.3+dfsg-2
ii  libao4                            1.2.2+20180113-1.1
ii  libasound2                        1.2.4-1.1
ii  libaudiofile1                      0.3.6-5
ii  libavahi-client3                  0.8-5
ii  libavahi-common3                  0.8-5
ii  libavcodec-extra58 [libavcodec58]  7:4.3.2-0+deb11u1
ii  libavformat58                      7:4.3.2-0+deb11u1
ii  libavutil56                        7:4.3.2-0+deb11u1
ii  libbz2-1.0                        1.0.8-4
ii  libc6                              2.31-12
ii  libcdio-cdda2                      10.2+2.0.0-1+b2
ii  libcdio-paranoia2                  10.2+2.0.0-1+b2
ii  libcdio19                          2.1.0-2
ii  libchromaprint1                    1.5.0-2
ii  libcurl3-gnutls                    7.74.0-1.2
ii  libdbus-1-3                        1.12.20-2
ii  libexpat1                          2.2.10-2
ii  libfaad2                          2.10.0-1
ii  libflac8                          1.3.3-2
ii  libfluidsynth2                    2.1.7-1.1
ii  libgcc-s1                          10.2.1-6
ii  libgme0                            0.6.3-2
ii  libicu67                          67.1-6
ii  libid3tag0                        0.1

Bug#996031: nvidia-driver breaks 'apt-get update' when kernel 5.14.6 is candidate kernel

[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, 
nvidia-dkms-compat, with the same version as nvidia-kernel-dkmsbut which 
conflicts with later kernel versions than the ones where nvidia-kernel-dkms was 
tested.
Users that want to keep the current informal status can avoid installing 
nvidia-dkms-compat and rely on the description of nvidia-driver to choose newer 
kernel versions.

Users that do install nvidia-dkms-compat will be alerted through the usual apt 
methods that there is an incompatibility with a newer kernel.
Regardless of how this is solved, I think an important goal is that apt-get 
upgrade should work properly when nvidia-kernel-dkms is installed;this means 
that a newer kernel on which nvidia does not build will not be installed by 
default, not appear as a candidate upgrade version.

thanks,--jack

Bug#950586: REDEFINITION: dkms build fails with kernel 5.4.0-3-686-pae but NOT with 4.17.0-3-686-pae

[js jb]

 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 first: 
this was because the install did notremove a number of packages from the old 
390.87 driver (listed below), including nvidia-kernel-support and 
nvidia-kernel-source,so that after the initial install the nvidia module was 
not found.
Removing the list of 390.87 packages fixed that problem: perhaps the new driver 
should have removed some of these packages.
I did not check the package description before upgrading, so missed the part 
that said it had been tested only through linux 4.20 kernel.Perhaps this would 
have been easier if the nvidia-driver package depended on a linux kernel 
version <= 4.20?
thanks again,--jack

List of nvidia 390.87 packages not remove after install nvidia-driver 440.44-2

libegl-nvidia0
libgl1-nvidia-glvnd-glx
libgl1-nvidia-glx-390.87
libgles-nvidia2
libglx-nvidia0
libnvidia-cfg1
libnvidia-compiler
libnvidia-compiler-390.87
libnvidia-eglcore
libnvidia-eglcore-390.87
libnvidia-encode1
libnvidia-fatbinaryloader
libnvidia-fatbinaryloader-390.87
libnvidia-glcore
libnvidia-glcore-390.87
libnvidia-ifr1
libnvidia-ml1
libnvidia-ptxjitcompiler1
nvidia-alternative
nvidia-cuda-mps
nvidia-detect
nvidia-driver-bin
nvidia-driver-bin-390.87
nvidia-driver-libs
nvidia-egl-icd
nvidia-kernel-390.87
nvidia-kernel-source
nvidia-kernel-support
nvidia-legacy-check
nvidia-opencl-icd
nvidia-vdpau-driver



On Monday, February 3, 2020, 4:27:39 PM EST, Andreas Beckmann 
 wrote:  
 
 On 03/02/2020 22.14, js wrote:
> I expected the dkms module would be built for 5.4 as it was for 4.17.

The nvidia kernel module build usually breaks with every new major
kernel release, e.g. 5.4 -> 5.5

> [I understand this is an older version of nvidia-kernel-dkms but did not

Please check the description of the package, it will tell you the
maximum kernel version where we successfully built the module for.
(Usually the current kernel version at the time the package was uploaded.)

> find a bug report regarding this and would normally not upgrade both
> kernel and nvidia at the same time.]

Then upgrade nvidia first. The driver should be backwards compatible.


Andreas
  

Bug#891578: xscreensaver often slows down, taking 1+ minute to respond to keystrokes, Xorg 100% CPU

[js jb]

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 when runin full screen mode.
Both xscreensaver and flightgear run fine in a window but slow down to a crawl 
in full screen modeonce X windows has been running continuously for 10+ days. 
Restarting X fixes the problem for another10 days or so.
thanks,--jack

Bug#895335: geeqie: edit-orientation corrupts EXIF in image

[js jb]

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) instead of a specific type.
Several tests with the camera and lens showed no problem with the EXIF.
I stumbled on the error and can now reproduce it; the problem is using any of 
the Edit->Orientation functionsin geeqie. Here is an example; after applying a 
rotate operation from geeqie, lens info is corrupted:

2018 => exiftool A6K01199.JPG | grep -i Lens
Lens Type   : E-Mount, T-Mount, Other Lens or no lens
Lens Spec   : E PZ 18-105mm F4 G OSS
Lens Mount 2    : E-mount
Lens Type 3 : Sony E PZ 18-105mm F4 G OSS
Lens E-mount Version    : 1.41
Lens Firmware Version   : Ver.04.003
Lens Mount  : E-mount
Lens Format : APS-C
Lens Type 2 : Sony E PZ 18-105mm F4 G OSS
Lens Spec Features  : E PZ G OSS
Lens Info   : 18-105mm f/4
Lens Model  : E PZ 18-105mm F4 G OSS
Lens ID : Sony E PZ 18-105mm F4 G OSS

["Apply the orientation to the image content"]  (also happens with losslessly 
rotate functions)

2018 => exiftool A6K01199.JPG | grep -i Lens
Lens Type   : E-Mount, T-Mount, Other Lens or no lens
Lens Spec   : Unknown (01 0 1 0 0 00)
Lens Mount 2    : Unknown (97)
Lens Type 3 : Unknown (38213)
Lens E-mount Version    : 47.61
Lens Firmware Version   : Ver.cf.069
Lens Mount  : Unknown
Lens Format : Unknown
Lens Spec Features  :
Lens ID : Sony E 16-70mm F4 ZA OSS or Sony FE 24-70mm 
F4 ZA OSS or Sony E PZ 18-105mm F4 G OSS or Sony FE 24-105mm F4 G OSS or ...

I have verified this does NOT happen when rotating the images with ristretto.
This is a serious issue if one takes large numbers of pictures, views them and 
later depends on the EXIF data.
===


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

Kernel: Linux 4.7.0-1-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages geeqie depends on:
ii  geeqie-common    1:1.4-3
ii  libatk1.0-0  2.28.1-1
ii  libc6    2.27-2
ii  libcairo2    1.15.10-1
ii  libexiv2-14  0.25-3.1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8-20180207-2
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.56.0-4
ii  libgtk2.0-0  2.24.32-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpangoft2-1.0-0    1.42.0-1
ii  libstdc++6   8-20180207-2
ii  libtiff5 4.0.9-4

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.7-1
ii  exiftran 2.10-2+b3
ii  exiv2    0.25-3.1
ii  imagemagick  8:6.9.9.34+dfsg-3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.34+dfsg-3
ii  librsvg2-common  2.40.20-2
ii  ufraw-batch  0.22-2
ii  zenity   3.27.90-1

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.20-1.1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw    
pn  xpaint   

-- no debconf information

Bug#894257: eog fails with 'BadAccess (attempt to access private resource denied)' for 6000x4000 JPG

[js jb]

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 on smaller 8MP files). This used to work as late as eog 
3.26 and there is no problemopening these files with ristretto or geeqie.
Below are some of the messages from /var/log/messages for eog and a backtrace 
of eog (withoug debug
symbols as eog-dbg 3.28 is not yet available on testing):



=> tail -5 /var/log/messages
Mar 27 07:55:04 localhost kernel: [125036.108772] traps: eog[11283] trap int3 
ip:b751e7b0 sp:bff40170 error:0 in libglib-2.0.so.0.5600.0[b74d+12e000]
Mar 27 11:36:20 localhost kernel: [138311.962382] traps: eog[13174] trap int3 
ip:b751f7b0 sp:bfc51240 error:0 in libglib-2.0.so.0.5600.0[b74d1000+12e000]
Mar 27 16:22:40 localhost kernel: [155492.314670] traps: eog[16015] trap int3 
ip:b754c7b0 sp:bfe79ad0 error:0 in libglib-2.0.so.0.5600.0[b74fe000+12e000]
Mar 27 16:23:04 localhost kernel: [155516.672124] traps: eog[16027] trap int3 
ip:b74fc7b0 sp:bfe0ce30 error:0 in libglib-2.0.so.0.5600.0[b74ae000+12e000]
Mar 27 16:27:52 localhost kernel: [155804.824810] traps: eog[16121] trap int3 
ip:b74fb7b0 sp:bfb5e950 error:0 in libglib-2.0.so.0.5600.0[b74ad000+12e000]


=> export GDK_SYNCHRONIZE=1
ME:=> gdb `which eog`
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 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 "i686-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 /usr/bin/eog...(no debugging symbols found)...done.
(gdb) b gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) r A6K01000.JPG
Starting program: /usr/bin/eog A6K01000.JPG
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb3bdeb40 (LWP 16053)]
[New Thread 0xb31ffb40 (LWP 16054)]
[New Thread 0xb27ffb40 (LWP 16055)]
[New Thread 0xb1dffb40 (LWP 16056)]
[New Thread 0xace2eb40 (LWP 16057)]

(eog:16049): Gdk-ERROR **: 16:24:09.919: The program 'eog' received an X Window 
System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 8188 error_code 10 request_code 130 (MIT-SHM) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Thread 1 "eog" received signal SIGTRAP, Trace/breakpoint trap.
0xb7d9e7b0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0xb7d9e7b0 in  () at /lib/i386-linux-gnu/libglib-2.0.so.0
#1  0xb7da0fa9 in g_log_writer_default () at 
/lib/i386-linux-gnu/libglib-2.0.so.0
#2  0xb7d9f32c in g_log_structured_array () at 
/lib/i386-linux-gnu/libglib-2.0.so.0
#3  0xb7d9f582 in g_log_structured () at /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb7038a0c in  () at /usr/lib/i386-linux-gnu/libgdk-3.so.0
#5  0xb70462c4 in  () at /usr/lib/i386-linux-gnu/libgdk-3.so.0
#6  0xb68d3b7a in _XError () at /usr/lib/i386-linux-gnu/libX11.so.6
#7  0xb68d077b in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#8  0xb68d083f in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#9  0xb68d1866 in _XReply () at /usr/lib/i386-linux-gnu/libX11.so.6
#10 0xb68ccf7f in XSync () at /usr/lib/i386-linux-gnu/libX11.so.6
#11 0xb68cd01a in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#12 0xb68d44d3 in  () at /usr/lib/i386-linux-gnu/libX11.so.6
#13 0xb63a2f23 in XShmAttach () at /usr/lib/i386-linux-gnu/libXext.so.6
#14 0xb6f3d2cd in  () at /usr/lib/i386-linux-gnu/libcairo.so.2
#15 0xb6f3de0f in  () at /usr/lib/i386-linux-gnu/libcairo.so.2
#16 0xb6f3deb4 in  () at /usr/lib/i386-linux-gnu/libcairo.so.2
#17 0xb6f0722b in cairo_surface_create_similar_image () at 
/usr/lib/i386-linux-gnu/libcairo.so.2
#18 0xb7001801 in gdk_cairo_set_source_pixbuf () at 
/usr/lib/i386-linux-gnu/libgdk-3.so.0
#19 0xb7f7fe80 in  () at /usr/lib/i386-linux-gnu/eog/libeog.so
#20 0xb7f827c2 in eog_scroll_view_set_image () 

Bug#818922: Please add explanation for converting firefox to firefox-esr in testing distribution

[js jb]

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 available in sid only,not in 
testing.

There is a very big time lag between the two versions which has a noticeable 
user impact: Amazon videos will no longer play on 52.6.0,displaying an error 
message to upgrade the browser, but they play fine in 58.0.1.
Perhaps both firefox and firefox-esr packages could find their way into testing 
to avoid this problem?
thanks,--jack

Bug#879786: apt-secure man page needs to provide useful pointers for Release file info changes

[js jb]

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, and to block all ubuntu packages other than the 2 codecs 
not available in debian.Plus block versions of some packages, like vivaldi 
browser, that no longer work well with the latest codecs. 
It there's a better way to achieve these goals, I'd very much like to learn 
about it.
thanks,--jack

  From: Julian Andres Klode 
 To: js ; 879...@bugs.debian.org 
 Sent: Wednesday, October 25, 2017 4:23 PM
 Subject: Re: Bug#879786: apt-secure man page needs to provide useful pointers 
for Release file info changes
   
On Wed, Oct 25, 2017 at 04:05:24PM -0400, js wrote:
> Package: apt
> Version: 1.5
> Severity: minor
> 
> Dear Maintainer,
> 
> ==
> I use only 2 packages from ubuntu (which are not available in debian): 
> chromium-codecs-ffmpeg-extra, oxideqt-codecs-extra.

The first one does not make much sense, Debian's chromium should already 
contain all codecs.


> For this I have the ubuntu repository in sources.list along with an 
> apt_preferences file to allow
> only those 2 packages (with priority 476 < 500 for all debian).
> 
> This recently gave these errors during apt-get update:
>  W: Conflicting distribution: http://archive.ubuntu.com/ubuntu devel 
>InRelease (expected devel but got bionic)
>  N: Repository 'http://archive.ubuntu.com/ubuntu devel InRelease' changed its 
>'Version' value from '17.10' to '18.04'
>  E: Repository 'http://archive.ubuntu.com/ubuntu devel InRelease' changed its 
>'Suite' value from 'artful' to 'bionic'
>  E: Repository 'http://archive.ubuntu.com/ubuntu devel InRelease' changed its 
>'Codename' value from 'artful' to 'bionic'
>  N: This must be accepted explicitly before updates for this repository can 
>be applied. See apt-secure(8) manpage for details.
> 
> The apt-secure man page is of no help in resolving this (see bottom).

That's somewhat true. You likely want to use apt instead of apt-get, that would 
ask
the question interactively. apt-get is mostly for scripting.

BTW, your pinning and sources.list is extreme. That's not really a sensible 
thing to do and can cause a lot
of trouble. Also, well, it took me a minute to clean them out for the reply - 
it can only delete one line
at a time :/

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
Ubuntu Core Developer