Bug#1080470: firefox: upgrade to firefox 130.0-1 does not access external sites

[js jb]

 >> That would indicate a bug to fix in libnss3 so that firefox picks the right 
 >> dependency.
I don't agree, it seems the firefox package depends on libnss >= 2:3.102~  when 
it should be requiring version 2:3.103-1:


=> apt-cache show firefox
Package: firefox
Version: 130.0-1
Installed-Size: 253448
Maintainer: Maintainers of Mozilla-related packages 

Architecture: amd64
Provides: gnome-www-browser, www-browser
Depends: ..., libnss3 (>= 2:3.102~),...

Note that images not coming up on some sites, like http://www.reuters.com, got 
fixed entirely by replacing these librarieswith the ones downloaded from 
Mozilla:
/usr/lib/x86_64-linux-gnu/libfreeblpriv3.so
/usr/lib/firefox/libgkcodecs.so
/usr/lib/firefox/libipcclientcerts.so
/usr/lib/firefox/liblgpllibs.so
/usr/lib/firefox/libmozavcodec.so
/usr/lib/firefox/libmozavutil.so
/usr/lib/firefox/libmozgtk.so
/usr/lib/firefox/libmozsandbox.so
/usr/lib/firefox/libmozsqlite3.so
/usr/lib/firefox/libmozwayland.so
/usr/lib/x86_64-linux-gnu/libnspr4.so
/usr/lib/x86_64-linux-gnu/libnss3.so
/usr/lib/x86_64-linux-gnu/libnssckbi.so
/usr/lib/x86_64-linux-gnu/libnssutil3.so
/usr/lib/x86_64-linux-gnu/libplc4.so
/usr/lib/x86_64-linux-gnu/libplds4.so
/usr/lib/x86_64-linux-gnu/libsmime3.so
/usr/lib/x86_64-linux-gnu/libsoftokn3.so
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/lib/firefox/libxul.so



The Amazon Video tab crashing happened 100% of the time, without fail, even 
after upgrading to the correct libnss3.I'm going to rebuild the firefox package 
using only the libraries and executables downloaded from Mozilla.

thanks,JS

On Thursday, September 5, 2024 at 12:09:56 AM EDT, Mike Hommey 
 wrote:  
 
 > 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

Thank you for fising this. That would indicate a bug to fix in libnss3
so that firefox picks the right 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 text.This was 
> fixed by copying the libraries from the direct mozilla download in  
> firefox/lib*.so  directly to /usr/lib/firefox , overstepping the libraries 
> from the package.
> It seems the libraries in the debian package do not correspond to what comes 
> from the mozilla download and prevents some sites, like 
> http://www.reuters.com, from displaying correctly.

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1916038

On Wed, Sep 04, 2024 at 09:05:01PM +, js jb wrote:
> Tabs running Amazon Prime videos crash constantly, within seconds of opening.

I cannot reproduce this behavior.

Mike
  

Bug#1080470: Amazon Prime videos tab constantly crashes

[js jb]

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,where the libnss3 
and libnspr4 packages put libraries of the same name, to get sites like 
reuters.com to display.
firefox_130.0-1 should be repackaged more carefully to include the correct 
Mozilla libraries and executable.

Bug#1080470: libraries with firefox_130.0-1 do NOT match mozilla

[js jb]

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/lib*.so  directly to /usr/lib/firefox , overstepping the libraries from 
the package.
It seems the libraries in the debian package do not correspond to what comes 
from the mozilla download and prevents some sites, like http://www.reuters.com, 
from displaying correctly.

Bug#1080470: firefox_130.0-1 package needs dependency on libnss3_2:3.103-1

[js jb]

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

Bug#1080470: LD_LIBRARY_PATH

[js jb]

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. 

Bug#1080470: firefox: upgrade to firefox 130.0-1 does not access external sites

[js]

Package: firefox
Version: 130.0-1
Severity: important

Dear Maintainer,

===
 
   Normal upgrade from firefox 129.0.2-1 to 130.0-1

   After this, the new firefox could not access external pages (but
   no problem with pages on the local subnet). However, it could only
   access google from the default new tab page but no pages in my
   bookmarks or start page.

   I tried this also with --no-profile and --safe-start and got the same
   results.

   I downloaded firefox 130.0 directly from the mozilla site and it runs
   fine, as does chrome on the same PC. This problem is limited to the
   debian packaging of firefox 130.0-1, not to firefox_130.0 from
   Mozilla.

   The debian package of firefox_130.0-1 is not functional and I had to
   revert to 129.0.2-1 to get a working, debian-packaged firefox
   browser again.


===


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
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 firefox depends on:
ii  debianutils  5.20
ii  fontconfig   2.15.0-1.1
ii  libasound2t641.2.12-1
ii  libatk1.0-0t64   2.52.0-1
ii  libc62.39-6
ii  libcairo-gobject21.18.0-3+b1
ii  libcairo21.18.0-3+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libevent-2.1-7t642.1.12-stable-10
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgcc-s114.2.0-1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libglib2.0-0t64  2.80.4-1
ii  libgtk-3-0t643.24.43-1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.102-1
ii  libpango-1.0-0   1.54.0+ds-1
ii  libstdc++6   14.2.0-1
ii  libvpx9  1.14.1-1
ii  libx11-6 2:1.8.7-1+b1
ii  libx11-xcb1  2:1.8.7-1+b1
ii  libxcb-shm0  1.17.0-2
ii  libxcb1  1.17.0-2
ii  libxcomposite1   1:0.4.5-1+b1
ii  libxdamage1  1:1.1.6-1+b1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2+b1
ii  libxrandr2   2:1.5.4-1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

Versions of packages firefox recommends:
ii  libavcodec-extra58 [libavcodec58]  7:4.4.2-1+b3
ii  libavcodec-extra60 [libavcodec60]  7:6.1.1-5+b1
ii  libavcodec-extra61 [libavcodec61]  7:7.0.2-3

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-5
ii  libcanberra0   0.30-17
ii  libgssapi-krb5-2   1.21.3-3
ii  pulseaudio 16.1+dfsg1-5

-- no debconf information

Bug#1076155: dpkg-query --search does not use partial pathnames as pattern

[js]

Package: dpkg
Version: 1.22.6
Severity: minor

Dear Maintainer,

===

dpkg-query does not use a partial pathname as a pattern to search.

Example:
  => which exiftool
   /bin/exiftool
  => dpkg-query --search `which exiftool`
   dpkg-query: no path found matching pattern /bin/exiftool
  => dlocate `which exiftool`
   libimage-exiftool-perl: /usr/bin/exiftool
  => dpkg-query --search /usr/bin/exiftool
   libimage-exiftool-perl: /usr/bin/exiftool
  => /bin/ls -lt /usr/bin/exiftool /bin/exiftool
   -rwxr-xr-x 1 root root 320936 Feb  2 19:43 /bin/exiftool
   -rwxr-xr-x 1 root root 320936 Feb  2 19:43 /usr/bin/exiftool

The behavior of dlocate, which takes "/bin/exiftool" as an argument and
returns the package containing /usr/bin/exiftool is more useful.

===


-- Package-specific info:

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5.1
ii  libc62.38-11
ii  liblzma5 5.4.5-0.3
ii  libmd0   1.1.0-2
ii  libselinux1  3.5-2+b2
ii  libzstd1 1.5.5+dfsg2-2
ii  tar  1.35+dfsg-3
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.9.5
ii  debsig-verify  0.30

-- Configuration Files:
/etc/dpkg/dpkg.cfg changed:
refuse-downgrade
no-debsig
log /var/log/dpkg.log


-- no debconf information

Bug#1069952: upgrade from 2.78.4-1 to 2.78.4-7 breaks over 200 packages in testing distribution

[js]

Package: libglib2.0-dev
Version: 2.78.4-1
Severity: important

Dear Maintainer,

==

   * What led up to the situation?
   Wanted to see the effect of upgrading libglib2.0-dev by a minor
   version number, 2.78.4-1 to 2.78.4-7 and that would have caused over
   200 packages to break in the **testing** distribution.

   My understanding is:
   1. minor version changes like -1 to -7 reflect only minor packaging
   changes, not something as disruptive as breaking so many packages
   2. testing distribution is not supposed have broken packages;
   packages should transition from unstable to testing only after
   dependencies are in place.

   It seems adding this minor version change into testing made this
   version of the library not usable because of all the other packages
   that have to be removed because of it. The change would have been
   better left in unstable until new versions of these packages were
   available so they could all move to testing in a non-disruptive way.

 The following packages will be REMOVED:
  anjuta atril balsa baresip-gstreamer bijiben blender brasero brasero-cdrkit 
cheese claws-mail-extra-plugins claws-mail-fancy-plugin cysignals-tools devhelp 
dleyna-renderer
  dleyna-server elisa empathy ephoto evince evolution evolution-data-server 
evolution-plugin-pstimport evolution-plugin-spamassassin evolution-plugins 
font-manager gdb
  gir1.2-clutter-gst-3.0 gir1.2-evince-3.0 gir1.2-gst-plugins-bad-1.0 
gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gir1.2-rb-3.0 gir1.2-totem-1.0 
gir1.2-webkit2-4.0
  gir1.2-webkit2-4.1 glade gnome-contacts gnome-flashback 
gnome-getting-started-docs gnome-music gnome-online-miners gnome-packagekit 
gnome-photos gnome-session-flashback
  gnome-shell gnome-software gnome-software-plugin-flatpak gnome-sound-recorder 
gnome-sushi gnome-user-docs gnome-user-guide gnome-video-effects gnucash 
goldendict
  google-earth-pro-stable grilo-plugins-0.3 gst123 gstreamer1.0-alsa 
gstreamer1.0-clutter-3.0 gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-libav 
gstreamer1.0-nice
  gstreamer1.0-packagekit gstreamer1.0-pipewire gstreamer1.0-plugins-bad 
gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly 
gstreamer1.0-pulseaudio
  gstreamer1.0-tools gstreamer1.0-x gthumb handbrake jupyter jupyter-console 
jupyter-notebook jupyter-qtconsole kdenlive kdevelop kdevelop-python 
kdevelop510-libs kdevelop512-libs
  kdevelop54-libs kdevelop55-libs kdevelop56-libs kmymoney knowthelist 
libatrilview3 libbrasero-media3-1 libcheese-gtk25 libcheese8 
libclutter-gst-3.0-0 libdebuginfod1
  libdevhelp-3-6 libdmapsharing-3.0-2 libdmapsharing-4.0-3 libdw-dev libdw1 
libedataserverui-1.2-4 libelementary1 libelf1 libemotion1 libevas-loaders 
libevolution libevview3-3
  libfarstream-0.2-5 libfolks-eds26 libgladeui-2-13 libglib2.0-0 
libgstreamer-gl1.0-0 libgstreamer-plugins-bad1.0-0 
libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev
  libgstreamer1.0-0 libgstreamer1.0-dev libgupnp-dlna-2.0-4 libkf5webkit5 
libopencv-videoio4.5d libopencv-videoio406 libopenimageio2.4 libpurple-bin 
libpurple0
  libqt5multimedia5-plugins libqt5multimediagsttools5 libqt5webkit5 
libqt6multimedia6 libreoffice libreoffice-base libreoffice-calc 
libreoffice-core libreoffice-draw
  libreoffice-evolution libreoffice-gnome libreoffice-gtk3 libreoffice-impress 
libreoffice-librelogo libreoffice-lightproof-en libreoffice-math 
libreoffice-nlpsolver
  libreoffice-report-builder libreoffice-report-builder-bin 
libreoffice-texmaths libreoffice-wiki-publisher libreoffice-writer 
libreoffice-writer2latex librhythmbox-core10
  librpmbuild8 librygel-renderer-gst-2.6-2 libtelepathy-farstream3 
libtorch-test libtorch2.0 libtotem0 libwebkit2gtk-4.0-37 libwebkit2gtk-4.1-0 
libwxgtk-media3.0-gtk3-0v5
  libwxgtk-media3.2-1 libwxgtk-webview3.0-gtk3-0v5 libyelp0 liferea midori 
mkvtoolnix-gui nautilus packagekit packagekit-tools parole 
phonon4qt5-backend-gstreamer pidgin
  pidgin-plugin-pack pulseaudio python3-apptools python3-debugpy 
python3-envisage python3-guidata python3-ipykernel python3-jupyter-console 
python3-notebook python3-pweave
  python3-pydevd python3-pyface python3-pyqt5.qtwebkit python3-qdarkstyle 
python3-qtawesome python3-qtconsole python3-qtpy python3-qwt python3-spyder 
python3-spyder-kernels
  python3-spyder-unittest python3-torch python3-traitsui python3-wxgtk-media4.0 
qml-module-qtwebkit qt5-assistant qtmultimedia5-dev qttools5-dev-tools 
quodlibet rednotebook
  rhythmbox rhythmbox-plugin-cdrecorder rhythmbox-plugins rkward rust-gdb 
shotwell software-properties-common software-properties-gtk sound-juicer spyder 
telepathy-haze totem
  totem-plugins tracker-extract tracker-miner-fs tumbler vitables webcamoid 
webcamoid-plugins wireshark wkhtmltopdf xfburn xfce4-goodies yelp

==

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#1051796: thunderbird: message headers NOT displayed in message list or message for some, not all, messages, OK in evolution, balsa

[js]

Package: thunderbird
Version: 1:117.0~b5-1
Severity: important

Dear Maintainer,

==

   * What led up to the situation?
 Thunderbird is my default mail client. Inbox has about 1300 mails
 in it and occassionally messages appear garbled (ie message headers
 not displayed or selected message in list doesn't match preview
 pane). Up to now, this was easily corrected by repairing the
 folder.

 Today (Sept 12) this is not the case: repairing the folder **very briefly 
**
 displays the headers correctly and then they disappear.

 Note that the mail folders themselves are fine: opening another
 email client (I tried evolution, balsa, claws-mail) displays
 correctly all the message headers missing from thunderbird.

 This is limited to thunderbird display of message headers. When replying
 to a message with empty From, To, Subject, thunderbird correctly
 fills in the missing fields (list of recipients, subject, etc.)

   * What exactly did you do (or not do) that was effective (or ineffective)?
 Repaired the folder several times, upgraded dbus and rebooted, but
 problem persists.

   * What outcome did you expect instead?
 In the past this behavior has sometimes happened, only in
 thunderbird (but not in other mail clients) and folder repair fixed
 it.


==

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
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 thunderbird depends on:
ii  debianutils  5.8-1
ii  fontconfig   2.14.2-3
ii  kdialog  4:22.12.3-1
ii  libasound2   1.2.9-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.37-5
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.10-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-3
ii  libfreetype6 2.13.1+dfsg-1
ii  libgcc-s113.2.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.2-1
ii  libgtk-3-0   3.24.38-2
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.50.14+ds-1
ii  libstdc++6   13.2.0-1
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2
ii  myspell-es [myspell-dictionary]   1.11-20
ii  myspell-fr [myspell-dictionary]   1.4-30
ii  myspell-he [myspell-dictionary]   1.4-3.1

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-2

-- no debconf information

Bug#1041190: nut.conf: MODE=none prevents system from booting, shuts down in middle of boot by UPS

[js]

Package: nut
Version: 2.8.0-7
Severity: important

Dear Maintainer,



   * What led up to the situation?
 /etc/nut.conf had MODE=none with 2 UPS connected to PC by USB cable
 and monitored by it. During reboot, the UPS clicked and powered
 down the PC (this happened twice).

   * What exactly did you do (or not do) that was effective (or ineffective)?
 To restore a working system I unplugged the USB cables to the UPS
 and rebooted, no problems encountered.

 Then I changed MODE=standalone and rebooted with USB cables plugged in
 and no other configuration changes at all, rebooted with no problem and
 was able to monitor both UPS devices. This seems to have fixed the issue.

   * What outcome did you expect instead?
 I would expect that regardless of the configuration in
 /etc/nut/nut.conf, the system will boot normally.

 UPS actions are for extreme situations like a major power loss and
 should not be invoked for a simple configuration error. Some
 message in syslog or other notification to root would have been
 more appropriate.

 Details:
 UPS-pc:  device.mfr: American Power Conversion device.model: Back-UPS 
RS 1500MS2
 UPS-network: device.mfr: American Power Conversion device.model: Back-UPS 
XS 1500M

 These lines from journalctl --system seem relevant during the aborted 
reboot:

Jul 14 16:39:57 MY_SYSTEM systemd[1]: Starting 
nut-driver-enumerator.service - Network UPS Tools - enumeration of 
configure-file devices into systemd unit instances...
Jul 14 16:39:57 MY_SYSTEM systemd[1]: Starting 
nut-driver@UPS-network.service - Network UPS Tools - device driver for NUT 
device 'UPS-network'...
Jul 14 16:39:57 MY_SYSTEM systemd[1]: Starting 
nut-driver@UPS-pc.service - Network UPS Tools - device driver for NUT device 
'UPS-pc'...
Jul 14 16:40:03 MY_SYSTEM nut-driver-enumerator[1032]: Fri Jul 14 
08:40:03 PM UTC 2023 : OK: No changes to reconcile between systemd service 
instances and device configurations in '/etc/nut/ups.conf'
Jul 14 16:40:03 MY_SYSTEM systemd[1]: nut-driver-enumerator.service: 
Deactivated successfully.
Jul 14 16:40:03 MY_SYSTEM systemd[1]: Finished 
nut-driver-enumerator.service - Network UPS Tools - enumeration of 
configure-file devices into systemd unit instances.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: Network UPS Tools - 
Generic HID driver 0.47 (2.8.0)
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: USB communication 
driver (libusb 1.0) 0.43
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: libusb1: Could not 
open any HID devices: insufficient permissions on everything
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1384]: No matching HID UPS 
found
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1275]: Driver failed to 
start (exit status=1)
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-pc[1275]: Network UPS Tools - 
UPS driver controller 2.8.0
Jul 14 16:40:06 MY_SYSTEM systemd[1]: nut-driver@UPS-pc.service: 
Control process exited, code=exited, status=1/FAILURE
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: Using 
subdriver: APC HID 0.98
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: Network UPS 
Tools - Generic HID driver 0.47 (2.8.0)
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: USB 
communication driver (libusb 1.0) 0.43
Jul 14 16:40:06 MY_SYSTEM systemd[1]: nut-driver@UPS-pc.service: Failed 
with result 'exit-code'.
Jul 14 16:40:06 MY_SYSTEM systemd[1]: Failed to start 
nut-driver@UPS-pc.service - Network UPS Tools - device driver for NUT device 
'UPS-pc'.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: ups_status_set: 
seems that UPS [UPS-network] is in OL+DISCHRG state now. Is it calibrating or 
do you perhaps want to set 'onlinedischarge' option? Some UPS models (e.g. 
CyberPower UT series) emit OL+DISCHRG when offline.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: using 
'battery.charge' to set battery low state
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1383]: using 
'battery.runtime' to set battery low state
Jul 14 16:40:06 MY_SYSTEM usbhid-ups[1383]: ups_status_set: seems that 
UPS [UPS-network] is in OL+DISCHRG state now. Is it calibrating or do you 
perhaps want to set 'onlinedischarge' option? Some UPS models (e.g. CyberPower 
UT series) emit OL+DISCHRG when offline.
Jul 14 16:40:06 MY_SYSTEM nut-driver@UPS-network[1276]: Network UPS 
Tools - UPS driver controller 2.8.0
Jul 14 16:40:06 MY_SYSTEM systemd[1]: Started 
nut-driver@UPS-network.service - Network UPS Tools - device driver for NUT 
device 'UPS-network'.
Jul 14 16:40:06 MY_SYSTEM systemd[1]: Reached target nut-driver.target 
- Network UPS Tools - target for power device drivers on t

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#1032972: handbrake: debian version of handbrake does NOT handle subtitles correctly

[js]

Package: handbrake
Version: 1.6.1+ds1-1
Severity: important

Dear Maintainer,

===

   * What led up to the situation?

Tried to convert 2 different DVDs, both NTSC, into m4v (or mp4)
including subtitles.

In both cases, using many different options for handbrake (H264,
H265, different audio encoders, etc), was easily able add subtitles
(as well as burn-in). HOWEVER: the subtitles NEVER worked correctly:
- there are places where characters speak and no subtitles appear at
  all
- also places where characters speak at length and a subtitle pops
  up for only a second
- parts where there is lenghty narration, but no character speaks, and no
  subtitle appears ever

NOTE: in both DVDs, playing the DVD directly results in subtitles
working perfectly. The DVDs have subtitles working but the debian
package of handbrake does not work.

   * What exactly did you do (or not do) that was effective (or ineffective)?

 I contacted handbrake.fr and they recommended using their nightly
 snapshot as they claim debian is using a version of ffmpeg that
 breaks subtitles.

 Entire thread is at: 
https://forum.handbrake.fr/viewtopic.php?p=202972#p202972

 Using the nightly snapshot from handbrake.fr worked perfectly and
 produced an m4v file with subtitles that match exactly the
 characters.

   * What outcome did you expect instead?

   I expected the debian packaged handbrake to work exactly as the one
   from the upstream source but it does not. Failure to generate all
   subtitles and insert them at the correct spot in the video is a major
   failure that makes this packaged version of handbrake unusable for
   videos with subtitles.

   I recommend adding a test case of ripping a DVD with subtitles AND
   verifying that the subtitles really match the speech.

===


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security

  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-1-amd64 (SMP w/6 CPU threads; PREEMPT)
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 handbrake depends on:
ii  libass91:0.17.0-2
ii  libavcodec-extra59 [libavcodec59]  7:5.1.2-3
ii  libavfilter-extra8 [libavfilter8]  7:5.1.2-3
ii  libavformat59  7:5.1.2-3
ii  libavutil577:5.1.2-3
ii  libbluray2 1:1.3.4-1
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libdvdnav4 6.1.1-1
ii  libdvdread86.1.3-1
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.5-1
ii  libgstreamer-plugins-base1.0-0 1.22.0-3
ii  libgstreamer1.0-0  1.22.0-2
ii  libgtk-3-0 3.24.36-4
ii  libgudev-1.0-0 237-2
ii  libjansson42.14-2
ii  libpango-1.0-0 1.50.12+ds-1
ii  libswresample4 7:5.1.2-3
ii  libswscale67:5.1.2-3
ii  libtheora0 1.1.1+dfsg.1-16.1
ii  libturbojpeg0  1:2.1.5-2
ii  libva-drm2 2.17.0-1
ii  libva2 2.17.0-1
ii  libvorbis0a1.3.7-1
ii  libvorbisenc2  1.3.7-1
ii  libvpl22023.1.1-1
ii  libx264-1642:0.164.3095+gitbaee400-2+b1
ii  libx265-1993.5-2+b1
ii  libxml22.9.14+dfsg-1.1+b3

Versions of packages handbrake recommends:
ii  gstreamer1.0-alsa1.22.0-3
ii  gstreamer1.0-libav   1.22.0-2
ii  gstreamer1.0-pulseaudio  1.22.0-4
ii  gstreamer1.0-x   1.22.0-3

handbrake suggests no packages.

-- no debconf information

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#1031249: vlc crashed in vdpau driver when playing DVD or .mpv file

[js]

Package: vlc
Version: 3.0.18-2
Severity: important

Dear Maintainer,

==

   * What led up to the situation?

   Tried to play DVD on drive, as has worked previously and get repeated
   crashes with vlc. Got the same result trying to play .m4v file.

   NOTE: DVD and .m4v files play perfectly with mpv on the same system
   with current libdvdcss2 and other packages

   (I'm unclear whether this relates to nvidia-drivers or vlc but chose
   vlc because these videos play fine with mpv and the same nvidia
   driver)

   * use mpv to play video files as the current work-around

   - Output of vlc --vvv /media/cdrom0:
   => vlc -vvv --color --list
  VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
  [559b51684cd0] main libvlc debug: VLC media player - 3.0.18 Vetinari
  [559b51684cd0] main libvlc debug: Copyright © 1996-2022 the VideoLAN team
  [559b51684cd0] main libvlc debug: revision 3.0.13-8-g41878ff4f2
  [559b51684cd0] main libvlc debug: configured with ./configure  
'--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' 
'--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
'--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' 
'--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' 
'--runstatedir=/run' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--disable-debug' '--config-cache' 
'--disable-update-check' '--enable-fast-install' '--docdir=/usr/share/doc/vlc' 
'--with-binary-version=3.0.18-2' '--enable-a52' '--enable-aa' 
'--enable-aribsub' '--enable-avahi' '--enable-bluray' '--enable-caca' 
'--enable-chromaprint' '--enable-chromecast' '--enable-dav1d' '--enable-dbus' 
'--enable-dca' '--enable-dvbpsi' '--enable-dvdnav' '--enable-faad' 
'--enable-flac' '--enable-fluidsynth' '--enable-freetype' '--enable-fribidi' 
'--enable-gles2' '--enable-gnutls' '--enable-harfbuzz' '--enable-jack' 
'--enable-kate' '--enable-libass' '--enable-libmpeg2' '--enable-libxml2' 
'--enable-lirc' '--enable-mad' '--enable-matroska' '--enable-mod' 
'--enable-mpc' '--enable-mpg123' '--enable-mtp' '--enable-ncurses' 
'--enable-notify' '--enable-ogg' '--enable-opus' '--enable-pulse' '--enable-qt' 
'--enable-realrtsp' '--enable-samplerate' '--enable-sdl-image' '--enable-sftp' 
'--enable-shine' '--enable-shout' '--enable-skins2' '--enable-soxr' 
'--enable-spatialaudio' '--enable-speex' '--enable-srt' '--enable-svg' 
'--enable-svgdec' '--enable-taglib' '--enable-theora' '--enable-twolame' 
'--enable-upnp' '--enable-vdpau' '--enable-vnc' '--enable-vorbis' 
'--enable-x264' '--enable-x265' '--enable-zvbi' 
'--with-kde-solid=/usr/share/solid/actions/' '--disable-aom' 
'--disable-crystalhd' '--disable-d3d11va' '--disable-decklink' 
'--disable-directx' '--disable-dsm' '--disable-dxva2' '--disable-fdkaac' 
'--disable-fluidlite' '--disable-freerdp' '--disable-goom' 
'--disable-gst-decode' '--disable-libtar' '--disable-live555' 
'--disable-macosx' '--disable-macosx-avfoundation' '--disable-macosx-qtkit' 
'--disable-mfx' '--disable-microdns' '--disable-opencv' '--disable-projectm' 
'--disable-schroedinger' '--disable-sndio' '--disable-sparkle' '--disable-telx' 
'--disable-vpx' '--disable-vsxu' '--disable-wasapi' '--enable-alsa' 
'--enable-dc1394' '--enable-dv1394' '--enable-libplacebo' '--enable-linsys' 
'--enable-nfs' '--enable-udev' '--enable-v4l2' '--enable-wayland' 
'--enable-vcd' '--enable-smbclient' '--disable-oss' '--enable-mmx' 
'--enable-sse' '--disable-neon' '--disable-altivec' '--disable-omxil' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-ffile-prefix-map=/build/vlc-WcXCHF/vlc-3.0.18=. -fstack-protector-strong 
-Wformat -Werror=format-security ' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 
-ffile-prefix-map=/build/vlc-WcXCHF/vlc-3.0.18=. -fstack-protector-strong 
-Wformat -Werror=format-security ' 'OBJCFLAGS=-g -O2 
-ffile-prefix-map=/build/vlc-WcXCHF/vlc-3.0.18=. -fstack-protector-strong 
-Wformat -Werror=format-security'
  [559b51684cd0] main libvlc debug: searching plug-in modules
  [559b51684cd0] main libvlc debug: loading plugins cache file 
/usr/lib/x86_64-linux-gnu/vlc/plugins/plugins.dat
  [559b51684cd0] main libvlc debug: recursively browsing 
`/usr/lib/x86_64-linux-gnu/vlc/plugins'
  [559b51684cd0] main libvlc debug: plug-ins loaded: 523 modules
  [559b51684cd0] main libvlc debug: opening config file 
(/home/jack/.config/vlc/vlcrc)
  [559b51685020] main logger debug: looking for logger module matching 
"any": 4 candidates
  [559b51685020] main logger debug: using logger module "console"
  [559b51684cd0] main libvlc debug: translation test: code is "C"
demux_cdg  CDG demuxer
vobsub Vobsub subtitles parser
es MPEG-I/II/4 / A52 / DTS / MLP audio
es  

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#1029815: fetchmail: logfile option ignored since version 6.4.33-2

[js]

Package: fetchmail
Version: 6.4.35-1
Severity: normal

Dear Maintainer,

=
Until version 6.4.33-2, it was possible to keep fetchmail output (-v -v)
in a user-specified logfile with these lines below in .fetchmailrc:
set logfile /var/tmp/fetchmail.log

This no longer works and syslog says logfile is ignored due to nodetach option:
fetchmail[1014123]: The nodetach option is in effect, ignoring logfile 
option.

This was not the case before 6.4.33-2 and the specified logfile was
populated everytime fetchmail was called, using the same, unchanged 
.fetchmailrc.
There seems to be no way to override this behavior and
keep verbose fetchmail output in a user-specified logfile.

fetchmail -V
This is fetchmail release 6.4.35+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.
Compiled with SSL library 0x3070 "OpenSSL 3.0.7 1 Nov 2022"
Run-time uses SSL library 0x3070 "OpenSSL 3.0.7 1 Nov 2022"
OpenSSL: OPENSSLDIR: "/usr/lib/ssl"
Engines: ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"

Copyright (C) 2002, 2003 Eric S. Raymond
Copyright (C) 2004 Matthias Andree, Eric S. Raymond,
   Robert M. Funk, Graham Wilson
Copyright (C) 2005 - 2012 Sunil Shetye
Copyright (C) 2005 - 2023 Matthias Andree
Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. For details,
please see the file COPYING in the source or documentation directory.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)

Fallback MDA: (none)
Linux LOCAL 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 
(2023-01-07) x86_64 GNU/Linux
Taking options from command line and /home/ME/.fetchmailrc
Poll interval is 330 seconds
Logfile is /var/tmp/fetchmail.log <
Idfile is /home/ME/.fetchids
Fetchmail will forward misaddressed multidrop messages to ME.
Options for retrieving from ME@MAIL ...

=


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/6 CPU threads; PREEMPT)
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 fetchmail depends on:
ii  adduser3.129
ii  debianutils5.7-0.4
ii  init-system-helpers1.65.2
ii  libc6  2.36-7
ii  libcom-err21.46.6~rc1-1.1
ii  libgssapi-krb5-2   1.20.1-1
ii  libkrb5-3  1.20.1-1
ii  libssl33.0.7-2
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

Versions of packages fetchmail recommends:
ii  ca-certificates  20211016

Versions of packages fetchmail suggests:
pn  fetchmailconf
pn  resolvconf   
ii  sendmail-bin [mail-transport-agent]  8.17.1.9-1

-- no debconf information

Bug#1028059: calibre-bin version 6.10.0+dfsg-5 uses unknown compression for control.tar.zst, cannot be installed

[js]

Package: calibre-bin
Version: 6.10.0+dfsg-3
Severity: important

Dear Maintainer,

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

Tried to install 6.10.0+dfsg-5 and got the error below:
calibre-bin_6.10.0+dfsg-5_amd64.deb' uses unknown compression for member 
'control.tar.zst', giving up

Forced to cancel upgrade, leaving a number of packages that cannot be
upgraded as they need the qt6 packages but I need a working calibre.

Full details:

dpkg-deb: error: archive 
'/var/cache/apt/archives/calibre-bin_6.10.0+dfsg-5_amd64.deb' uses unknown 
compression for member 'control.tar.zst', giving up
Traceback (most recent call last):
  File "/usr/share/apt-listchanges/DebianFiles.py", line 124, in readdeb
output = subprocess.check_output(command)
  File "/usr/lib/python3.10/subprocess.py", line 421, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.10/subprocess.py", line 526, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['dpkg-deb', '-f', 
'/var/cache/apt/archives/calibre-bin_6.10.0+dfsg-5_amd64.deb', 'Package', 
'Source', 'Version', 'Architecture', 'Status']' returned non-zero exit status 2.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/bin/apt-listchanges", line 323, in 
main(config)
  File "/usr/bin/apt-listchanges", line 104, in main
pkg = DebianFiles.Package(deb)
  File "/usr/share/apt-listchanges/DebianFiles.py", line 358, in __init__
parser.readdeb(self.path)
  File "/usr/share/apt-listchanges/DebianFiles.py", line 127, in readdeb
raise RuntimeError(_("Error processing '%(what)s': %(errmsg)s") %
RuntimeError: Error processing 
'/var/cache/apt/archives/calibre-bin_6.10.0+dfsg-5_amd64.deb': Command 
'['dpkg-deb', '-f', 
'/var/cache/apt/archives/calibre-bin_6.10.0+dfsg-5_amd64.deb', 'Package', 
'Source', 'Version', 'Architecture', 'Status']' returned non-zero exit status 2.


*** End of the template - remove these template lines ***


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/6 CPU threads; PREEMPT)
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 calibre-bin depends on:
ii  libc6   2.36-5
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.2.0-11
ii  libhunspell-1.7-0   1.7.1-1
ii  libhyphen0  2.8.8-7
ii  libicu7272.1-2
ii  libmtp9 1.1.20-1
ii  libpodofo0.9.8  0.9.8+dfsg-3
ii  libpython3.10   3.10.9-1
ii  libqt6core6 [qt6-base-abi]  6.3.1+dfsg-10+b1
ii  libqt6gui6  6.3.1+dfsg-10+b1
ii  libqt6widgets6  6.3.1+dfsg-10+b1
ii  libstdc++6  12.2.0-11
ii  libstemmer0d2.2.0-2
ii  libuchardet00.0.7-1
ii  libusb-1.0-02:1.0.26-1

Versions of packages calibre-bin recommends:
ii  calibre6.10.0+dfsg-3
pn  qt6-image-formats-plugins  

calibre-bin suggests no packages.

-- no debconf information

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
i

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 () at

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

[js]

Package: xscreensaver
Version: 5.36-1
Severity: normal

Dear Maintainer,

==

After upgrading to nvidia-driver 384.111, I've noticed that after the X
server has been running for a few days, running xscreensaver can
sometimes slow down enormously, taking more than 1 minute just to
respond to a keystroke and bring up a dialog box to unlock.

At those times, getting into the system with ssh shows Xorg is at 100%
of CPU (for one core).

None of the other graphics-intensive applications, like flightgear or
playing videos in full screen mode, show any such problem on the system.
This also happens when running the Preview in xscreensaver-demo (for full
screen mode) but do not happen when xscreensaver-demo is NOT in full
screen mode.

These are the versions of nvidia-driver and xserver-xorg-core in use:
ii  nvidia-driver  384.111-1  i386  
 NVIDIA metapackage
ii  xserver-xorg-core  2:1.19.6-1 i386  
 Xorg X server - core server

When this slowdown happens, getting out of X Windows and restarting X
fixes the problem (for a few days). Note that the system boots in
console mode and X is started manually, so this is not the same as
rebooting the system.

[I realize this could be a problem with the nvidia driver or with the X
server but since xscreensaver is the only graphics application showing
this behavior, it seemed the logical place to start.]

==



-- 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 xscreensaver depends on:
ii  libatk1.0-0  2.26.1-2
ii  libc62.26-2
ii  libcairo21.15.10-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.54.3-1
ii  libgtk2.0-0  2.24.32-1
ii  libice6  2:1.0.9-2
ii  libpam0g 1.1.8-3.6
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangoft2-1.0-01.40.14-1
ii  libsm6   2:1.2.2-1+b3
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.3-1+b3
ii  libxml2  2.9.4+dfsg1-6.1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.36-1

Versions of packages xscreensaver recommends:
ii  libgnomeui-0  2.24.5-3.2
ii  libjpeg-turbo-progs   1:1.5.2-2+b1
pn  perl5 
ii  wamerican [wordlist]  2017.08.24-1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]  62.0.3202.89-1
ii  firefox [www-browser]   59.0~b4-1
ii  firefox-esr [www-browser]   52.6.0esr-2
ii  fortune-mod [fortune]   1:1.99.1-7+b1
pn  gdm3 | kdm-gdmcompat
ii  google-chrome-stable [www-browser]  48.0.2564.116-1
ii  konqueror [www-browser] 4:17.08.3-2
ii  midori [www-browser]0.5.11-ds1-4+b1
ii  opera [www-browser] 12.16.1860
ii  opera-developer [www-browser]   46.0.2573.0
ii  opera-next [www-browser]12.16.1860
pn  qcam | streamer 
ii  qupzilla [www-browser]  2.2.5~dfsg1-1
ii  vivaldi-snapshot [www-browser]  1.15.1104.3-1
ii  vivaldi-stable [www-browser]1.14.1077.50-1
ii  w3m [www-browser]   0.5.3-35
pn  xdaliclock  
ii  xemacs21-mule [www-browser] 21.4.24-4
pn  xfishtank   
ii  xscreensaver-data-extra 5.36-1
ii  xscreensaver-gl 5.36-1
ii  xscreensaver-gl-extra   5.36-1

-- no debconf information

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#887404: libreoffice: LibreOffice eats up 100%CPU even without any document loaded

[JS Ubei]

Yes I confirm that disabling gtk3 UI by executing:
export SAL_USE_VCLPLUGIN=gensoffice &
resolves the issue for me.
Regards

Bug#887404: libreoffice: LibreOffice eats up 100%CPU even without any document loaded

[JS Ubei]

Hello,
I'm also affected by this bug. Same debian buster version and same libreoffice 
version also.I'm using Gnome(Wayland) and I don't have the Zotero Plugin.
Best regards,
Jsubei

Bug#883291: ristretto: Image properties need to include Aperture and other metadada

[js]

Package: ristretto
Version: 0.8.2-1
Severity: normal

Dear Maintainer,

=

At the bottom is the metadata reported by jhead on some jpegs.

When viewing image properties with ristretto, the following important
attributes do NOT appear:
- Aperture
- Whitebalance

Eog reports Aperture value under Image Properties -> Metadata and
whitebalance under Image Properties -> Details.

Please consider adding at least Aperture and Whitebalance to the image
properties displayed by ristretto. These are very useful when looking at
a group of test pictures to evaluate lens performance and camera
settings.

Also, both eog and ristretto list "Exposure Program" = "Normal program" but the
result from jhead "program (auto)" is more accurate and maps directly to camera 
settings.


File name: OptZoomF4-A6K00049.JPG
File size: 21463040 bytes
File date: 2017:12:01 14:04:22
Camera make  : SONY
Camera model : ILCE-6500
Date/Time: 2017:12:01 13:41:50
Resolution   : 6000 x 4000
Flash used   : No
Focal length : 95.0mm  (35mm equivalent: 142mm)
Exposure time: 0.0063 s  (1/160)
Aperture : f/4.0  <<< missing
ISO equiv.   : 400
Whitebalance : Auto   <<< missing
Metering Mode: pattern
Exposure : program (auto)   < better
GPS Latitude : ? ?
GPS Longitude: ? ?
JPEG Quality : 100


=


-- 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 ristretto depends on:
ii  libc62.24-5
ii  libcairo21.14.10-1
ii  libdbus-glib-1-2 0.108-2
ii  libexif120.6.21-2.1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.1-1
ii  libgtk2.0-0  2.24.31-2
ii  libmagic11:5.32-1
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libx11-6 2:1.6.4-3
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

Versions of packages ristretto recommends:
ii  tumbler  0.1.32-1

ristretto suggests no packages.

-- no debconf information

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


   

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

[js]

 
non-free
deb-src  http://snapshot.debian.org/archive/debian/20160201/ testing main 
contrib non-free

# get systemd 215-10 and linux-image-686-pae:
deb  http://snapshot.debian.org/archive/debian/20150201/ testing main contrib 
non-free
deb-src  http://snapshot.debian.org/archive/debian/20150201/ testing main 
contrib non-free

# get last before gcc 5:
deb  http://snapshot.debian.org/archive/debian/20150904/ testing main contrib 
non-free
deb-src  http://snapshot.debian.org/archive/debian/20150904/ testing main 
contrib non-free

# get udev=221
deb  http://snapshot.debian.org/archive/debian/20150720/ testing main contrib 
non-free
deb-src  http://snapshot.debian.org/archive/debian/20150720/ testing main 
contrib non-free

# get nvidia 340.46-1 driver and linux-image-3.14-1-686-pae 
(snapshot.debian.org)
##deb  http://snapshot.debian.org/archive/debian/20141018/ testing main contrib 
non-free
##deb-src  http://snapshot.debian.org/archive/debian/20141018/ testing main 
contrib non-free


# get nvidia 340.24-2 driver and linux-image-3.14-1-686-pae 
(snapshot.debian.org)
##deb  http://snapshot.debian.org/archive/debian/20140727/ testing main contrib 
non-free
##deb-src  http://snapshot.debian.org/archive/debian/20140727/ testing main 
contrib non-free

### get nvidia 331.67-1 driver (snapshot.debian.org)
##deb  http://snapshot.debian.org/archive/debian/20140504/ testing main contrib 
non-free
##deb-src  http://snapshot.debian.org/archive/debian/20140504/ testing main 
contrib non-free
##
### get nvidia 331.49-1 driver (snapshot.debian.org)
##deb  http://snapshot.debian.org/archive/debian/20140319/ testing main contrib 
non-free
##deb-src  http://snapshot.debian.org/archive/debian/20140319/ testing main 
contrib non-free

# get nvidia 319.82-1 driver (snapshot.debian.org)
#deb  http://snapshot.debian.org/archive/debian/20140219/ testing main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20140219/ testing main 
contrib non-free

# get xorg-video-all (snapshot.debian.org)
#deb  http://snapshot.debian.org/archive/debian/20140201/ testing main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20140201/ testing main 
contrib non-free

# get xorg-video-all (snapshot.debian.org)
#deb  http://snapshot.debian.org/archive/debian/20131102/ testing main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20131102/ testing main 
contrib non-free

# xbmc/kodi for videos:
#deb https://people.debian.org/~rbalint/ppa/xbmc-ffmpeg xbmc-ffmpeg-unstable/

# get nvidia 319.72-1 driver (snapshot.debian.org)
#deb  http://snapshot.debian.org/archive/debian/20131122/ testing main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20131122/ testing main 
contrib non-free

# get working chromium browser
#deb  http://snapshot.debian.org/archive/debian/20130831/ testing main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20130831/ testing main 
contrib non-free

# get linux-image-686-pae 3.2-35-1 
#deb  http://snapshot.debian.org/archive/debian/20130220/ testing main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20130220/ testing main 
contrib non-free

# get nvidia 304.64-4 driver and xorg 1:7.7-1 (snapshot.debian.org)
#deb  http://snapshot.debian.org/archive/debian/20130207/ wheezy main contrib 
non-free
#deb-src  http://snapshot.debian.org/archive/debian/20130207/ wheezy main 
contrib non-free

# libgl1-mesa-dev 9.1.6-2 (snapshot.debian.org)
## deb http://snapshot.debian.org/archive/debian/20130919T094745Z/ testing main 
contrib non-free
## deb-src http://snapshot.debian.org/archive/debian/20130919T094745Z/ testing 
main contrib non-free

# get 0.2.2 of glx-alternative-mesa glx-alternative-nvidia glx-diversions: 
(snapshot.debian.org)
##deb http://snapshot.debian.org/archive/debian/20130110/ wheezy main 
contrib non-free
##deb-src http://snapshot.debian.org/archive/debian/20130110/ wheezy main 
contrib non-free

# gnome-shell-3.4.2-16 (snapshot.debian.org)
#deb http://snapshot.debian.org/archive/debian/20131006T034833Z testing main 
contrib non-free
#deb-src http://snapshot.debian.org/archive/debian/20131006T034833Z testing 
main contrib non-free

# gdm3-3.4.1-9: (snapshot.debian.org)
#deb http://snapshot.debian.org/archive/debian/20130713/ testing main contrib 
non-free
#deb-src http://snapshot.debian.org/archive/debian/20130713/ testing main 
contrib non-free

# libaudit1-1.2.2.1: 
## deb http://snapshot.debian.org/archive/debian/20130519/  testing main 
contrib non-free
## deb-src http://snapshot.debian.org/archive/debian/20130519/  testing main 
contrib non-free

# fix for eclipse 3.7.2-1 until 3.8 upstream starts properly again:
#deb http://snapshot.debian.org/archive/debian/20120327T225039Z/ wheezy 
main contrib non-free
#deb-src http://snapshot.debian.org/archive/debian/20120327T225039Z/ wheezy 
main contrib non-free

##JS: use to catch last sun-java6:
#deb http://snapshot.debian.org

Bug#867593: dovecot-core 1:2.2.31-1 upgrade does not have valid certs in /etc/dovecot/private

[JS]

I checked from my backups, there was only a dovecot.pem (not a dovecot.key file 
there) from 4 years ago:
=> /bin/ls -lt etc/dovecot/private/total 4-rw--- 1 me  me  1704 Jun  6  
2013 dovecot.pem=>
What happened with the install is that, without a matching dovecot.key file, 
dovecot cannot start.It's only functional if  *** both ***  dovecot.key and 
dovecot.pem are present, so if at least one of these is missing,the postinstall 
script has to take action, not just when both are missing.
The postinstall script could easily issue a warning if it has to repair a 
partial setup, such as a missing dovecot.keybut an existing dovecot.pem. 
thanks,--jack

  From: Apollon Oikonomopoulos 
 To: JS ; 867...@bugs.debian.org 
 Sent: Monday, July 10, 2017 9:22 AM
 Subject: Re: Bug#867593: dovecot-core 1:2.2.31-1 upgrade does not have valid 
certs in /etc/dovecot/private
   
Hi,

On 01:51 Mon 10 Jul    , JS wrote:
> hello,
> It's possible this is the problem in the post-install script (there was a 
> dovecot.key, only, in the directory, don't know where it came from):
> 
>   # SSL configuration  # Use the ssl-cert-snakeoil certificate in the 
> following cases:  # - On new installations  # - On upgrades from versions 
> that did not enable SSL by default  if [ -z "$2" ] || dpkg --compare-versions 
> "$2" lt "1:2.2.31-1~"; then    if [ ! -e /etc/dovecot/private/dovecot.key ] 
> && \                                            ### only works if  *** both 
> ***  dovecot.key and dovecot.pem are missing       [ ! -e 
> /etc/dovecot/private/dovecot.pem ]; then      ln -s 
> /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/dovecot/private/dovecot.pem      ln 
> -s /etc/ssl/private/ssl-cert-snakeoil.key /etc/dovecot/private/dovecot.key    
> fi  fi
> 
> Perhaps this should have been:if [ ! -e /etc/dovecot/private/dovecot.key ] || 
> [ ! -e /etc/dovecot/private/dovecot.pem ]    ### if  *** either *** 
> dovecot.key OR dovecot.pem missing, create default symlinksthen   /bin/mv 
> /etc/dovecot/private/dovecot.key    /etc/dovecot/private/dovecot.key-OLD 
> 2>/dev/null || true   /bin/mv /etc/dovecot/private/dovecot.pem  
> /etc/dovecot/private/dovecot.pem-OLD 2>/dev/null || true
>   # create *** both ***  default symlinks:   ln -s 
> /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/dovecot/private/dovecot.pem  ln -s 
> /etc/ssl/private/ssl-cert-snakeoil.key /etc/dovecot/private/dovecot.keyfi    
> thanks,--jack

I was trying to be conservative there, to make sure I will never 
overwrite key material that the sysadmin might have created. The mtime 
of dovecot.key would probably help, could you please provide that?

Thanks,
Apollon


   

Bug#867593: dovecot-core 1:2.2.31-1 upgrade does not have valid certs in /etc/dovecot/private

[js]

Package: dovecot-core
Version: 1:2.2.31-1
Severity: important

Dear Maintainer,


==
   * What led up to the situation?
   During the upgrade from 1:2.2.27-3 to 1:2.2.31-1, the post-install script 
produced the message
   below and dovecot was not functional anymore:

Restarting IMAP/POP3 mail server: dovecotdoveconf: Fatal: Error in 
configuration file /etc/dovecot/conf.d/10-ssl.conf line 13:
ssl_key: Can't open file /etc/dovecot/private/dovecot.key: No such file or 
directory
 failed!


   * What exactly did you do (or not do) that was effective (or ineffective)?
   To fix this, I changed /etc/dovecot/conf.d/10-ssl.conf with the lines:

#   create symlinks in /etc/dovecot/private to default certificates:
## ssl-cert-snakeoil.key -> /etc/ssl/private/ssl-cert-snakeoil.key
## ssl-cert-snakeoil.pem -> /etc/ssl/certs/ssl-cert-snakeoil.pem

ssl_cert = 
ii  dovecot-managesieved  1:2.2.31-1
ii  dovecot-mysql 1:2.2.31-1
ii  dovecot-pgsql 1:2.2.31-1
ii  dovecot-pop3d 1:2.2.31-1
ii  dovecot-sieve 1:2.2.31-1
ii  dovecot-solr  1:2.2.31-1
ii  dovecot-sqlite1:2.2.31-1
pn  ntp   

Versions of packages dovecot-core is related to:
ii  dovecot-core [dovecot-common]  1:2.2.31-1
pn  dovecot-dbg
ii  dovecot-dev1:2.2.31-1
ii  dovecot-gssapi 1:2.2.31-1
ii  dovecot-imapd  1:2.2.31-1
ii  dovecot-ldap   1:2.2.31-1
ii  dovecot-lmtpd  1:2.2.31-1
ii  dovecot-managesieved   1:2.2.31-1
ii  dovecot-mysql  1:2.2.31-1
ii  dovecot-pgsql  1:2.2.31-1
ii  dovecot-pop3d  1:2.2.31-1
ii  dovecot-sieve  1:2.2.31-1
ii  dovecot-sqlite 1:2.2.31-1

-- Configuration Files:
/etc/init.d/dovecot changed:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="IMAP/POP3 mail server"
NAME=dovecot
DAEMON=/usr/sbin/dovecot
DAEMON_ARGS=""
SCRIPTNAME=/etc/init.d/$NAME
CONF=/etc/dovecot/${NAME}.conf
NICE="-N 8"
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
[ -x "$DAEMON" ] || exit 0
[ -f "$CONF" ] || exit 0
[ "$ENABLED" != "0" ] || exit 0
[ "$ALLOW_COREDUMPS" != "1" ] || ulimit -c unlimited
. /lib/lsb/init-functions
if [ ! -r ${CONF} ]; then
  log_daemon_msg "${CONF}: not readable" "$NAME" && log_end_msg 1;
  exit 1;
fi
if [ -f /etc/inetd.conf ]; then
  # The init script should do nothing if dovecot or another imap/pop3 server
  # is being run from inetd, and dovecot is configured to run as an imap or
  # pop3 service
  for p in `sed -r "s/^ *(([^:]+|\[[^]]+]|\*):)?(pop3s?|imaps?)[ \t].*/\3/;t;d" 
\
/etc/inetd.conf`
  do
for q in `doveconf -n -h protocols`
do
  if [ $p = $q ]; then
log_daemon_msg "protocol ${p} configured both in inetd and in dovecot" 
"$NAME" && log_end_msg 1
exit 0
  fi
done
  done
fi
PIDBASE=${PIDBASE:-`doveconf -n -c ${CONF} -h base_dir`}
PIDFILE=${PIDBASE:-/var/run/dovecot}/master.pid
do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON $NICE 
--test -- -c ${CONF} > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON $NICE 
-- -c ${CONF} \
$DAEMON_ARGS \
|| return 2
}
do_stop()
{
# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE 
--name ${DAEMON##*/}
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently.  A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --pidfile 
$PIDFILE --name ${DAEMON##*/}
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE $NICE 
--name $NAME
return 0
}
case "$1" in
  start)
log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
  stop)
log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
 

Bug#864749: debian-goodies: checkrestart false positives due to piping process output to tmp file

[JS]

Thanks, I'm aware of the linux file system hierarchy.
The file where this output is piped is not in /tmp so it can be preserved 
across reboots and not in /var/tmp as it's on a per-user basis.It's in a 
per-user directory that is cleaned out nightly of files older than X days.
It seems to me that the problem is checkrestart can't distinguish between an 
output file, which should not require a restart,and a changed library, which 
would. thanks,--jack

  From: Axel Beckert 
 To: js ; 864...@bugs.debian.org 
 Sent: Tuesday, June 13, 2017 7:47 PM
 Subject: Re: Bug#864749: debian-goodies: checkrestart false positives due to 
piping process output to tmp file
   
Control: tag -1 + wontfix

Hi,

js wrote:
> I start X from a console with roughly this command:
>     startx > /usr1/ME/.remove/junk.X 2>&1

In the subject, you said something about "piping process output to tmp
file", but this path you're using is not a common path for temporary
files, hence checkrestart can't recognize that you consider this to
be a temporary file.

In contrary, /usr1 is very similar to /usr which is cleary _no_
directory where tempfiles should be. Please see the Filesystem
Hierachy Standard at
https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html for how
directories are and should be used on Debian.

        Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'  |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


   

Bug#862679: vivaldi-snapshot: poor performance playing videos

[js]

Package: vivaldi-snapshot
Version: 1.10.845.3-1
Severity: important

Dear Maintainer,

===
This version of vivaldi-snapshot has very poor performance, especially
playing videos. Simply upgrading from version  1.9.804.3-1, the ***last***
version of vivaldi-snapshot that was *** not *** plagued by poor performance
made this netflix video replay so poorly the voice was out of sync with
the images and the video was very choppy:

 
https://www.netflix.com/watch/80085155?trackId=15036064&tctx=0%2C0%2Ceccfcd0b-aa9a-4a66-884d-01d2fbd9d413-45050469
 

The same link works perfectly when using 1.9.804.3-1, without any other change
to the system.

This happens even with the nice value for vivaldi-snapshot set to -5:

  PID   USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND   

  
  29371 jack  15  -5 1197656 190640 115184 S   5.5  0.8   0:17.69 
vivaldi-bin 

  30011 jack  15  -5  397584  99092  76936 S   4.1  0.4   0:01.48 
vivaldi-bin 

  29469 jack  15  -5  579280 174292  77472 S   3.6  0.7   0:06.94 
vivaldi-bin 

  29553 jack  15  -5  559248 218564 150244 S   1.9  0.9   0:11.65 
vivaldi-bin 

  29429 jack  15  -5  441996 186144  82444 S   1.4  0.7   0:04.61 
vivaldi-bin  

===


-- System Information:
Debian Release: 9.0
  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=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#838766: virtualbox-qt: segfault while deleting a snapshot on a VM with two virtual hard drives

[js]

Package: virtualbox-qt
Version: 5.1.6-dfsg-2+b1
Severity: important

Dear Maintainer,

I am using VirtualBox (from the Debian repositories) for virtualisation. One of
my VMs uses two virtual hard drives (Fixed-size VDIs of 120 GBytes each,
visible to the guest as SATA drives). I am trying to delete the oldest snapshot
on this VM, so the "original" (fixed-size) VDI files are to be modified as
changes are merged back into them from the oldest "difference" VDIs. Snapshot
deletion was triggered using the "delete snaphot" button in the QT GUI; the
host system was freshly booted, and no VMs were running.
VirtualBox merges the "difference" VDI back into the first fixed-size VDI. It
then deletes the "difference" VDI from the host filesystem, but instead of
working on the second virtual disk, the progress indicator just disappears. The
snapshot is still visible; the Virtual media Manager lists the "difference" VDI
that was just being deleted as "missing" (so obviously, the media registry was
not updated).
dmesg delivers the message "[  868.272600] DeleteSnap[2018]: segfault at 31 ip
0052bf8c sp 7fb4b7b6d9c0 error 4 in VBoxSVC[40+482000]" (the
precediung and following lines are not associated with VirtualBox). I have no
hints of physical media errors in the kernel log, so I consider the hard drive
as OK here.
htop shows that I am now having a total of three active VirtualBox processes,
which load two physical CPU cores at 100% each.

The expected behaviour would have been that nothing crashes, the VirtualBox
media registry is updated correctly, and the second virtual disk is processed
as well. Then, the configuration file for this VM shall be updated according to
the snapshot deletion, and the snapshot shall disappear from the snapshot tree.

I restored the VM from a backup and tried again, with the same result (however,
I did not check  dmesg and htop in the 2nd attempt).

The last time I deleted snapshots for this VM was with VirtualBox 5.0.24; I did
not have trouble there. VirtualBox 5.1.6 now shows the described behaviour.

I have no problems with deleting snapshots for VMs that have only one virtual
hard drive in VirtualBox 5.1.6, so this seems to be linked to the number of
virtual drives.



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

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

Versions of packages virtualbox-qt depends on:
ii  libc6 2.24-3
ii  libgcc1   1:6.2.0-4
ii  libgl1-mesa-glx [libgl1]  12.0.3-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5opengl5 5.6.1+dfsg-3+b1
ii  libqt5printsupport5   5.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libqt5x11extras5  5.6.1-2
ii  libstdc++66.2.0-4
ii  libx11-6  2:1.6.3-1
ii  libxcb1   1.11.1-1.1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  virtualbox5.1.6-dfsg-2+b1

virtualbox-qt recommends no packages.

virtualbox-qt suggests no packages.

-- no debconf information

Bug#819198: Missing libapache2-mod-auth-radius on Debian 8.3 mirrors.

[Js]

Package: libapache2-mod-auth-radius
Version: 1.5
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

The package libapache2-mod-auth-radius is not on Debian mirrors. I did not find
why this package was excluded from mirrors. Is there a new way to configure
Apache authentication against RADIUS server? Thank You very much in advance.



-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#807983: apt-cache policy no longer displays pinning info

[JS]

Thanks for the reply David,
I can live with looking at apt-cache policy and seeing all the pinned packages.
But I still count on apt-cache policy to disambiguate between different 
candidate versions of a package, as it does whenmultiple repositories are in 
the sources.list.
In that case, if the candidate package was chosen due to a pin, the Pin: line 
would display that explicitly and if multiple pinsapply to the package, only 
the ones that resulted in that candidate would be displayed (for example if one 
Pin was by versionand the other by origin).
Alternatively, it would be just as useful if in listing the possible 
candidates, the pin information affecting each was added (if relevant),just as 
different repositories are listed. thanks,--jack shaio
 

  From: David Kalnischkies 
 To: js ; 807983-d...@bugs.debian.org 
 Sent: Wednesday, December 23, 2015 1:06 PM
 Subject: Re: Bug#807983: apt-cache policy no longer displays pinning info
   
On Mon, Dec 14, 2015 at 09:29:29PM -0500, js wrote:
> Restoring this behavior would make it much easier to see why a package
> is kept at a version that is not the latest.
> 
> [Perhaps this is related to the change in 1.1~exp9 to the pinning algorithm?]

The problem with this Pin: line was that you can have both multiple pins
effecting (different) versions of a package and a pin effecting multiple
versions. What to display in these cases?

Julian (and I) therefore decided to drop this line as it tends to be
more confusing than helpful.

Have a look at the end of the output of "apt-cache policy" for a list of
all package (versions) effected by pins. The output changed slightly
with 1.1, but the list itself exists also in earlier versions. Also, if
you look very closely at the package specific policy display you can see
now that the version you specified is pinned to 1001.

I hope that helps you getting over the "loss" as both is intend to be
the better replacement, but feel free to report back if that isn't
working for you. Marking the bug as closed in the meantime as I don't
see Pin: coming back as-was.


Best regards

David Kalnischkies

  

Bug#797330: vim-gtk: update dependency on liblua5.2-0 to at least 5.2.4-1

[js]

Package: vim-gtk
Version: 2:7.4.826-1
Severity: minor

Dear Maintainer,


After upgrading to version 2:7.4.826-1   I noticed this error when editing any 
file:

  => vi ~/debian/debian-linux-admin
  vi: /usr/lib/i386-linux-gnu/liblua5.2.so.0: no version information available 
(required by vi)

At the time I had liblua5.2-0 version 5.2.3-1.1 and the vim upgrade did not 
pull in a newer version of that package.

The problem was fixed by manually upgrading liblua5.2-0:
  2015-08-29 11:17:08 upgrade liblua5.2-0:i386 5.2.3-1.1 5.2.4-1

Perhaps the dependencies should require a version >= 5.2.4-1 for this version 
of vim.gtk?




-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk
/usr/bin/vim is /usr/bin/vim.gtk
/usr/bin/gvim is /usr/bin/vim.gtk

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

Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages vim-gtk depends on:
ii  libacl1 2.2.52-2
ii  libc6   2.19-18
ii  libgdk-pixbuf2.0-0  2.31.4-2
ii  libglib2.0-02.44.1-1
ii  libgpm2 1.20.4-6.1+b2
ii  libgtk2.0-0 2.24.28-1
ii  libice6 2:1.0.9-1+b1
ii  liblua5.2-0 5.2.4-1
ii  libpango-1.0-0  1.36.8-3
ii  libperl5.20 5.20.2-6
ii  libpython2.72.7.10-1
ii  libruby2.1  2.1.5-2
ii  libselinux1 2.3-2
ii  libsm6  2:1.2.2-1+b1
ii  libtcl8.6   8.6.4+dfsg-2
ii  libtinfo5   6.0+20150810-1
ii  libx11-62:1.6.3-1
ii  libxt6  1:1.1.4-1+b1
ii  vim-common  2:7.4.826-1
ii  vim-gui-common  2:7.4.826-1
ii  vim-runtime 2:7.4.826-1

vim-gtk recommends no packages.

Versions of packages vim-gtk suggests:
ii  cscope15.8a-2
ii  fonts-dejavu  2.35-1
ii  gnome-icon-theme  3.12.0-1
ii  vim-doc   2:7.4.826-1

-- no debconf information

Bug#770031: Fw: Re: Bug#760075 closed by Jérémy Bobbio (Bug#760075: fixed in torsocks 2.1.0-1)

[JS]

I saw the same error "Unsupported syscall number 242" in torsocks_2.1.0-1  in a 
system using the debian testing distribution.
This version of torsocks had worked well before but following an apt-get 
upgrade, it now produces a stream of these errors.



thanks,
--jack


--- On Thu, 7/2/15, JS  wrote:

> From: JS 
> Subject: Re: Bug#760075 closed by Jérémy Bobbio  
> (Bug#760075: fixed in torsocks 2.1.0-1)
> To: 760...@bugs.debian.org
> Date: Thursday, July 2, 2015, 12:05 AM
> This bug had been fixed in torsocks_2.1.0-1 and I verified torify worked with
> browsers midori, iceweasel, qupzilla and konqueror.
> 
> However, after an apt-get upgrade each of those browsers now fails with the 
> error:
> Unsupported syscall number 242
> This error message is repeated indefinitely.
> 
> Replacing this version of torsocks with torsocks_1.3-3  fixes the problem 
> with all of these
> browsers in the upgraded system.
> 
> thanks,
> --jack
> 
> 
> On Tue, 6/2/15, Debian Bug Tracking System
> 
> wrote:
> 
>  Subject: Bug#760075 closed
> by Jérémy Bobbio 
> (Bug#760075: fixed in torsocks 2.1.0-1)
>  To:
> "js" 
>  Date: Tuesday, June 2, 2015, 6:24 AM
>  
>  This is an automatic
> notification
>  regarding your Bug report
>  which was filed against the torsocks
> package:
>  
>  #760075:
> torsocks: SIGSEGV with torsocks 2.0.0 on some
>  browsers, failure to anonimize others
>  
>  It has been closed by
> Jérémy Bobbio .
>  
>  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
>  Jérémy Bobbio 
>  by
>  replying to this email.
>  
>  
>  -- 
>  760075: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760075
>  Debian Bug Tracking System
> 
> Contact ow...@bugs.debian.org
>  with problems


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

Bug#760075: closed by Jérémy Bobbio (Bug#760075: fixed in torsocks 2.1.0-1)

[JS]

This bug had been fixed in torsocks_2.1.0-1 and I verified torify worked with 
browsers midori, iceweasel, qupzilla and konqueror.

However, after an apt-get upgrade each of those browsers now fails with the 
error: Unsupported syscall number 242
This error message is repeated indefinitely.

Replacing this version of torsocks with torsocks_1.3-3  fixes the problem with 
all of these browsers in the upgraded system.

thanks,
--jack


On Tue, 6/2/15, Debian Bug Tracking System  wrote:

 Subject: Bug#760075 closed by Jérémy Bobbio  (Bug#760075: 
fixed in torsocks 2.1.0-1)
 To: "js" 
 Date: Tuesday, June 2, 2015, 6:24 AM
 
 This is an automatic notification
 regarding your Bug report
 which was filed against the torsocks package:
 
 #760075: torsocks: SIGSEGV with torsocks 2.0.0 on some
 browsers, failure to anonimize others
 
 It has been closed by Jérémy Bobbio .
 
 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
 Jérémy Bobbio 
 by
 replying to this email.
 
 
 -- 
 760075: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760075
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org
 with problems


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

Bug#790130: xfce4-notes-plugin: uses incorrect directory for Adwaita theme (.../tabs instead of .../Tabs)

[js]

Package: xfce4-notes-plugin
Version: 1.8.0-1+b1
Severity: minor

Dear Maintainer,

=
I noticed on startup that xfce4-notes-plugin is using the wrong
directory for some pixmaps for the Adwaita theme.

This directory is now (note upper case Tabs):
/usr/share/themes/Adwaita/gtk-2.0/Tabs/tab-bottom.png

while xfce4-notes-plugin uses .../tabs/

This is a minor issue but affects appearance somewhat. Temporarily I
made a symlink from tabs to Tabs.

/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:55: Unable to locate image 
file in pixmap_path: "tabs/tab-bottom.png"
/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:59: Background image options 
specified without filename
/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:63: Unable to locate image 
file in pixmap_path: "tabs/tab-top.png"
/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:67: Background image options 
specified without filename
/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:71: Unable to locate image 
file in pixmap_path: "tabs/tab-left.png"
/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:75: Background image options 
specified without filename
/usr/share/xfce4-notes-plugin/gtk-2.0/notes.gtkrc:126: Unable to locate image 
file in pixmap_path: "tabs/notebook.png"
...

=


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

Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xfce4-notes-plugin depends on:
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-18
ii  libcairo21.14.2-2
ii  libdbus-1-3  1.8.18-1
ii  libdbus-glib-1-2 0.102-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libglib2.0-0 2.44.1-1
ii  libgtk2.0-0  2.24.28-1
ii  libice6  2:1.0.9-1+b1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsm6   2:1.2.2-1+b1
ii  libx11-6 2:1.6.3-1
ii  libxfce4util74.12.1-2
ii  libxfconf-0-24.12.0-2+b1
ii  xfce4-notes  1.8.0-1+b1
ii  xfce4-panel  4.12.0-2

xfce4-notes-plugin recommends no packages.

xfce4-notes-plugin 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#789119: libnettle6 install leaves libnettle4, causing segfaults on many applications

[JS]

Magnus,

Thanks very much for looking at this issue as it affected an unpredictable 
number of applications after a seemingly innocent
addition of libnettle6.

I don't recall any other packages being removed or upgraded when I removed 
libnettl4 (as I had just done an
apt-get upgrade so there were no newer candidates). apt-cache rdepends 
libnettle4 shows no packages.

This is a brief snapshot of package changes when I removed libnettle4:

2015-06-16 21:58:18 status installed libarchive12:i386 3.0.4-3+nmu1
2015-06-16 21:58:19 remove libgnutls28:i386 3.2.15-1 
2015-06-16 21:58:19 status installed libgnutls28:i386 3.2.15-1
2015-06-16 21:58:20 status installed libc-bin:i386 2.19-18
2015-06-16 21:58:22 upgrade dnsmasq-base:i386 2.72-3 2.72-3.1+b1
2015-06-16 21:58:24 upgrade librtmp1:i386 2.4+20150115.gita107cef-1 
2.4+20150115.gita107cef-1+b2
2015-06-16 21:58:26 upgrade rtmpdump:i386 2.4+20150115.gita107cef-1 
2.4+20150115.gita107cef-1+b2
2015-06-16 21:58:29 status installed dbus:i386 1.8.18-1
2015-06-16 21:58:29 status installed man-db:i386 2.7.0.2-5
2015-06-16 21:58:30 status installed libhogweed2:i386 2.7.1-5
2015-06-16 21:58:31 remove libhogweed2:i386 2.7.1-5  
<<<<<<<<<<<<<<<<<<<<<<
2015-06-16 21:58:32 status installed libc-bin:i386 2.19-18
2015-06-16 21:58:33 upgrade wget:i386 1.16.3-2 1.16.3-2+b2
2015-06-16 21:58:36 upgrade gstreamer1.0-plugins-bad:i386 1.4.5-2 1.4.5-2+b1
2015-06-16 21:58:39 upgrade libgstreamer-plugins-bad1.0-0:i386 1.4.5-2 
1.4.5-2+b1
2015-06-16 21:58:41 upgrade libarchive13:i386 3.1.2-11 3.1.2-11+b1
2015-06-16 21:58:43 status installed man-db:i386 2.7.0.2-5
2015-06-16 21:58:47 status installed install-info:i386 5.2.0.dfsg.1-6
2015-06-16 21:58:48 status installed libnettle4:i386 2.7.1-5
2015-06-16 21:58:49 remove libnettle4:i386 2.7.1-5 
<<<<<<<<<<<<<<<<
2015-06-16 21:58:50 status installed libc-bin:i386 2.19-18


thanks,
 Jack Shaio


On Mon, 6/22/15, Magnus Holmgren  wrote:

 Subject: Re: Bug#789119: libnettle6 install leaves libnettle4, causing 
segfaults on many applications
 To: "js" , 789...@bugs.debian.org
 Date: Monday, June 22, 2015, 1:26 PM
 
 onsdagen den 17 juni 2015 21.07.40
 skrev  js:
 > I did an apt-get upgrade of my system which brought in
 libnettle6 but
 > did not remove the existing libnettle4. After this
 upgrade, many
 > applications including curl, opera-developer,
 claws-mail and amarok gave
 > segfaults in libnettle.so.4.7, when they had been
 working very well
 > before the upgrade (set portion of /var/log/messages
 below).
 
 Installing a new SOversion of a library normally doesn't
 cause the old 
 SOversion to be deinstalled. libnettle4 merely existing on
 the system cannot 
 cause the segfaults; if it is loaded it's because something
 is linked with it. 
 
 > After removing libnettle4, all these applications work
 perfectly again.
 
 Did removing libnettle4 not cause any other package to be
 removed or upgraded?
 
 > I saw that other libnettle bugs that reported this
 behavior on specific
 > applications, like bugs 788349 and 788572, recommend
 updating the
 > affected packages. But the applications above that
 segfaulted in my
 > system were all at their latest version for debian
 testing, so this is
 > not a practical solution.
 
 Note that it's not enough that the applications that crash
 are the latest 
 version; the problem likely is that one of the intermediate
 libraries are not 
 upgraded and still use libnettle4.
 
 > One solution that would have avoided this issue is if
 installing libnettle6
 > caused an existing version of libnettle4 to be removed,
 for example by
 > making libnettle6 replace/conflict with libnettle4.
 Removing libnettle4
 > worked with all the applications that segfaulted in my
 system.
 
 As noted, that shouldn't technically be necessary, but we
 may have to do it 
 anyway to help the users. Now libgnutls-deb0-28, which is
 the most common 
 culprit, has been made to conflict with libnettle4 and
 libhogweed2.
 
 -- 
 Magnus Holmgren        holmg...@debian.org
 Debian Developer


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

Bug#789119: libnettle6 install leaves libnettle4, causing segfaults on many applications

[js]

Package: libnettle6
Version: 3.1.1-3
Severity: normal

Dear Maintainer,


===

I did an apt-get upgrade of my system which brought in libnettle6 but
did not remove the existing libnettle4. After this upgrade, many
applications including curl, opera-developer, claws-mail and amarok gave
segfaults in libnettle.so.4.7, when they had been working very well
before the upgrade (set portion of /var/log/messages below).

After removing libnettle4, all these applications work perfectly again.

I saw that other libnettle bugs that reported this behavior on specific
applications, like bugs 788349 and 788572, recommend updating the
affected packages. But the applications above that segfaulted in my
system were all at their latest version for debian testing, so this is
not a practical solution.

One solution that would have avoided this issue is if installing libnettle6
caused an existing version of libnettle4 to be removed, for example by
making libnettle6 replace/conflict with libnettle4. Removing libnettle4
worked with all the applications that segfaulted in my system.

Here is the recent update history of libnettle[46] on my system and
below all the libnettle segfaults in /var/log/messages, which began
only after libnettle6 was installed.


2015-04-23 10:53:00 upgrade libnettle4:i386 2.7.1-1 2.7.1-5
2015-04-23 12:12:25 configure libnettle4:i386 2.7.1-5 
2015-04-23 12:12:25 status installed libnettle4:i386 2.7.1-5
2015-06-14 18:26:02 install libnettle6:i386  3.1.1-3
2015-06-14 18:26:31 configure libnettle6:i386 3.1.1-3 
2015-06-14 18:26:32 status installed libnettle6:i386 3.1.1-3
2015-06-16 21:58:48 status installed libnettle4:i386 2.7.1-5
2015-06-16 21:58:49 remove libnettle4:i386 2.7.1-5 



=> grep libnettle /var/log/messages
Jun 15 02:15:32 berkeley kernel: [459177.083670] curl[2215]: segfault at 10 ip 
b6e6a788 sp bf9b0a80 error 4 in libnettle.so.4.7[b6e48000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.091692] curl[2218]: segfault at 10 ip 
b6ec3788 sp bfb73a60 error 4 in libnettle.so.4.7[b6ea1000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.098661] curl[2220]: segfault at 10 ip 
b6e91788 sp bf852660 error 4 in libnettle.so.4.7[b6e6f000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.106114] curl[2223]: segfault at 10 ip 
b6eb9788 sp bfd30850 error 4 in libnettle.so.4.7[b6e97000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.187186] curl[2227]: segfault at 10 ip 
b6e5a788 sp bf9c3610 error 4 in libnettle.so.4.7[b6e38000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.193226] curl[2230]: segfault at 10 ip 
b6eac788 sp bfaf4fe0 error 4 in libnettle.so.4.7[b6e8a000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.197596] curl[2232]: segfault at 10 ip 
b6ea5788 sp bf987f60 error 4 in libnettle.so.4.7[b6e83000+33000]
Jun 15 02:15:32 berkeley kernel: [459177.208119] curl[2235]: segfault at 10 ip 
b6eb9788 sp bfd8a5e0 error 4 in libnettle.so.4.7[b6e97000+33000]
Jun 15 02:15:33 berkeley kernel: [459177.265111] curl[2239]: segfault at 10 ip 
b6dd5788 sp bfd4bc20 error 4 in libnettle.so.4.7[b6db3000+33000]
Jun 15 02:15:33 berkeley kernel: [459177.276310] curl[2242]: segfault at 10 ip 
b6eb0788 sp bfa8d970 error 4 in libnettle.so.4.7[b6e8e000+33000]
Jun 15 11:13:54 berkeley kernel: [491510.386415] opera_autoupdat[19988]: 
segfault at 10 ip b6860788 sp bfc06df0 error 4 in 
libnettle.so.4.7[b683e000+33000]
Jun 15 17:18:54 berkeley kernel: [513431.641748] opera_autoupdat[21398]: 
segfault at 10 ip b67ea788 sp bf8a4550 error 4 in 
libnettle.so.4.7[b67c8000+33000]
Jun 15 22:21:51 berkeley kernel: [531625.841437] pool[24113]: segfault at 
ade29000 ip adbe9fe2 sp 9cbb2678 error 4 in libnettle.so.6.1[adbe3000+3c000]
Jun 15 22:23:24 berkeley kernel: [531718.780823] pool[24192]: segfault at 
add21000 ip ade2dfe2 sp 9fdc8678 error 4 in libnettle.so.6.1[ade27000+3c000]
Jun 15 22:28:48 berkeley kernel: [532044.064167] pool[24452]: segfault at 
add29000 ip adb3ffe2 sp 99662678 error 4 in libnettle.so.6.1[adb39000+3c000]
Jun 15 22:29:01 berkeley kernel: [532056.696990] pool[24493]: segfault at 
add21000 ip adb3ffe2 sp a21dd678 error 4 in libnettle.so.6.1[adb39000+3c000]
Jun 15 22:30:22 berkeley kernel: [532137.466226] pool[24546]: segfault at 
add21000 ip adb3ffe2 sp a21de678 error 4 in libnettle.so.6.1[adb39000+3c000]
Jun 15 22:50:56 berkeley kernel: [533373.264094] pool[25412]: segfault at 
add63000 ip adb3ffe2 sp 9a67e678 error 4 in libnettle.so.6.1[adb39000+3c000]
Jun 15 23:01:28 berkeley kernel: [534005.720854] pool[25876]: segfault at 
add54000 ip ade2bfe2 sp 9713f678 error 4 in libnettle.so.6.1[ade25000+3c000]
Jun 15 23:02:05 berkeley kernel: [534042.343145] pool[25923]: segfault at 
add26000 ip adb3ffe2 sp a0ecc678 error 4 in libnettle.so.6.1[adb39000+3c000]
Jun 15 23:02:35 berkeley kernel: [534072.861234] pool[25973]: segfault at 
add22000 ip adb3ffe2 sp a23de678 error 4 in libnettle.so.6.1[adb39000+3c000]
Jun 15 2

Bug#787620: many libnettle4 segmentation faults after installing libnettle6

[js]

Package: libnettle6
Version: 3.1.1-3
Followup-For: Bug #787620

Dear Maintainer,

===
I did an apt-upgrade which brought in libnettle6. After this upgrade,
many applications including claws-mail, opera-developer and amarok gave
segfaults in libnettle.so.4.7, when they had been working very well
before the upgrade.

A small portion of /var/log/messages shows the issue:

Jun 16 21:44:36 berkeley kernel: [  193.926118] opera-developer[5831]: segfault 
at 10 ip b58c7788 sp bf967fb0 error 4 in libnettle.so.4.7[b58a5000+33000]
Jun 16 21:44:40 berkeley kernel: [  198.120705] claws-mail[6013]: segfault at 
10 ip b5d4a788 sp bfc42ee0 error 4 in libnettle.so.4.7[b5d28000+33000]
Jun 16 21:45:53 berkeley kernel: [  270.450074] opera-developer[6033]: segfault 
at 10 ip b5921788 sp bfab6c40 error 4 in libnettle.so.4.7[b58ff000+33000]
Jun 16 21:49:34 berkeley kernel: [  492.247703] opera-developer[7105]: segfault 
at 10 ip b587c788 sp bfc2c040 error 4 in libnettle.so.4.7[b585a000+33000]
Jun 16 21:52:32 berkeley kernel: [  670.290937] amarok[7901]: segfault at 10 ip 
ae721788 sp bfc8bf70 error 4 in libnettle.so.4.7[ae6ff000+33000]
Jun 16 21:52:33 berkeley kernel: [  671.039250] amarok[7905]: segfault at 10 ip 
ae750788 sp bff04910 error 4 in libnettle.so.4.7[ae72e000+33000]
Jun 16 21:52:37 berkeley kernel: [  675.542855] amarok[7919]: segfault at 10 ip 
ae796788 sp bfc39c40 error 4 in libnettle.so.4.7[ae774000+33000]
Jun 16 21:52:42 berkeley kernel: [  679.686201] amarok[7941]: segfault at 10 ip 
ae742788 sp bfb02200 error 4 in libnettle.so.4.7[ae72+33000]
Jun 16 21:52:51 berkeley kernel: [  688.816133] amarok[7995]: segfault at 10 ip 
ae70d788 sp bfe147b0 error 4 in libnettle.so.4.7[ae6eb000+33000]
Jun 16 21:53:01 berkeley kernel: [  699.385685] amarok[8028]: segfault at 10 ip 
ae798788 sp bfec1e50 error 4 in libnettle.so.4.7[ae776000+33000]

After removing libnettle4, all these applications work perfectly again!

This (very serious) issue might have been avoided if the dependencies
for libnettle6 caused libnettle4 to be removed as part of the upgrade.

Here is a summary of the recent install history of libnettle on my
system:


2015-04-23 12:12:25 status installed libnettle4:i386 2.7.1-5
2015-06-14 18:26:02 install libnettle6:i386  3.1.1-3
2015-06-14 18:26:31 configure libnettle6:i386 3.1.1-3 
2015-06-14 18:26:32 status installed libnettle6:i386 3.1.1-3
2015-06-16 21:58:48 status installed libnettle4:i386 2.7.1-5
2015-06-16 21:58:49 remove libnettle4:i386 2.7.1-5 

===


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

Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

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

libnettle6 recommends no packages.

libnettle6 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#785406: xfce4: submenu no longer displays if it contains only other submenus but no items

[js]

Package: xfce4
Version: 4.12.1
Severity: normal

Dear Maintainer,

===

After upgrading xfce4 (from 0.5.4-1 to 0.8.0-2) I noticed that just one
of the submenus I had customized with xdg-desktop-menu no longer
displayed. It was the only only one that contained only other
(non-empty) submenus but no individual items.

When I added one filename to this submenu, it then displayed fully,
including all its submenus. This was not necessary previously with xfce4 
0.5.4-1.

Here is the piece of the ~/.config/menus/my.menu file that didn't
display in application launchers or the general applications menu in
xfwm4 until I added the extra item:

  
Internet
Internet.directory ### entire Internet directory 
did not appear

   
Browsers-opera.desktop  ### needed 
to add just one Filename
   ### for Internet and 
submenus to appear


 Browsers
 Browsers.directory

 
Jack-Browsers
 



 Email
 Email.directory
 
Jack-Email
 



 Network
 Network.directory
 
Jack-Network
 


   

This is a major inconvenience until one finds the cause.

===


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

Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce  3.2.0-2
ii  libxfce4ui-utils   4.12.1-2
ii  orage  4.12.1-1+b1
ii  thunar 1.6.8-2
ii  xfce4-appfinder4.12.0-2
ii  xfce4-mixer4.10.0-3+b1
ii  xfce4-panel4.12.0-2
ii  xfce4-session  4.12.1-2
ii  xfce4-settings 4.12.0-2
ii  xfconf 4.12.0-2+b1
ii  xfdesktop4 4.12.1-2
ii  xfwm4  4.12.2-3

Versions of packages xfce4 recommends:
ii  desktop-base  8.0.2
ii  tango-icon-theme  0.8.90-5
ii  thunar-volman 0.8.1-2
ii  xfce4-notifyd 0.2.4-3
ii  xorg  1:7.7+7

Versions of packages xfce4 suggests:
ii  gtk3-engines-xfce3.2.0-2
ii  xfce4-goodies4.10
ii  xfce4-power-manager  1.4.4-3+b1

-- 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#785391: parole: keyboard volume key lowers volume but never raises it

[js]

Package: parole
Version: 0.8.0-2
Severity: normal

Dear Maintainer,



After upgrading xfce4 (from 0.5.4-1 to 0.8.0-2) and xfce4 (from 4.10.1
to 4.12.1), I found that most keyboard multimedia keys still work when
parole is playing a playlist (pause/play/stop, advance track, rewind
track).

However, the volume key only lowers the volume but never raises it.
I verified this by checking the volume in pavucontrol, where parole ends
up in silence (eventually) and raising the volume key does nothing.

This behavior affects only parole 0.8.0-2. It did not happen with the
earlier parole 0.5.4-1 and it does not happen after the upgrade with
other music players, including xine and amarok.

This is actually a great inconvenience as it's nice to run parole
minimized and be able to change volume using only the keyboard.

2015-05-15 08:36:05 upgrade xfce4:all 4.10.1 4.12.1
2015-05-15 08:40:01 upgrade parole:i386 0.5.4-1 0.8.0-2




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

Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages parole depends on:
ii  gstreamer1.0-libav  1.4.4-2
ii  gstreamer1.0-plugins-bad [gstreamer1.0-audiosink]   1.4.4-2.1+b1
ii  gstreamer1.0-plugins-base   1.4.4-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-audiosink]  1.4.4-2
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.4.4-2
ii  gstreamer1.0-x  1.4.4-2
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18
ii  libcairo-gobject2   1.14.0-2.1
ii  libcairo2   1.14.0-2.1
ii  libdbus-1-3 1.8.16-1
ii  libdbus-glib-1-20.102-1
ii  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgstreamer-plugins-base1.0-0  1.4.4-2
ii  libgstreamer1.0-0   1.4.4-2
ii  libgtk-3-0  3.14.5-1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libtagc01.9.1-2.1
ii  libx11-62:1.6.2-3
ii  libxfce4ui-2-0  4.12.1-2
ii  libxfce4util7   4.12.1-2
ii  libxfconf-0-2   4.10.0-3

parole recommends no packages.

Versions of packages parole suggests:
ii  gnome-codec-install0.4.7+nmu2
ii  gstreamer1.0-plugins-bad   1.4.4-2.1+b1
ii  gstreamer1.0-plugins-ugly  1.4.4-2+b1

-- 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#761582: random files also missing with jmtpfs and Motorola Droid Turbo

[JS]

I've been able to use jmtpfs with Motorola Droid Turbo phone and mount it to 
see most, but not all files.

I created backup files named Backup_.zip.  Some of them are visible in 
the mounted system but others do not appear,
although they can be seen in the phone. Newer files created with camera 
software do appear, however.

It's not clear why some .zip files appear and others do not.

thanks,
--jack

[Already reported a separate bug that this device is unknown to libmtp: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782080 ]


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

Bug#782080: libmtp-runtime: missing Motorola Droid Turbo Device 0 (VID=22b8 and PID=2ea8) is UNKNOWN

[js]

Package: libmtp-runtime
Version: 1.1.8-1+b1
Severity: normal

Dear Maintainer,

=

The Motorola Droid Turbo phone is missing in libmtp. This is the message when 
mounting it:

Unable to open ~/.mtpz-data for reading, MTPZ disabled.
Device 0 (VID=22b8 and PID=2ea8) is UNKNOWN.
Please report this VID/PID and the device model to the libmtp
development team
Android device detected, assigning default bug flags

Device details from /var/log/messages:

new high-speed USB device number 11 using ehci-pci
Apr  7 09:16:03 berkeley kernel: [132875.367235] usb 4-2: New USB device found, 
idVendor=22b8, idProduct=2ea8
Apr  7 09:16:03 berkeley kernel: [132875.367240] usb 4-2: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Apr  7 09:16:03 berkeley kernel: [132875.367243] usb 4-2: Product: XT1254
Apr  7 09:16:03 berkeley kernel: [132875.367246] usb 4-2: Manufacturer: motorola
Apr  7 09:16:03 berkeley kernel: [132875.367248] usb 4-2: SerialNumber: 
ZX1F23859M
Apr  7 09:16:03 berkeley kernel: [132875.368916] usb-storage 4-2:1.1: USB Mass 
Storage device detected
Apr  7 09:16:03 berkeley kernel: [132875.371567] scsi16 : usb-storage 4-2:1.1
Apr  7 09:16:03 berkeley mtp-probe: checking bus 4, device 11: 
"/sys/devices/pci:00/:00:1d.7/usb4/4-2"
Apr  7 09:16:03 berkeley mtp-probe: bus: 4, device: 11 was an MTP device
Apr  7 09:16:04 berkeley kernel: [132876.370560] scsi 16:0:0:0: CD-ROM Linux
File-CD Gadget   0310 PQ: 0 ANSI: 2

=



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

Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libmtp-runtime depends on:
ii  libc6  2.19-13
ii  libmtp-common  1.1.8-1
ii  libmtp91.1.8-1+b1

libmtp-runtime recommends no packages.

libmtp-runtime 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#772471: closed by Michael Gilbert (Re: Bug#772471: chromium crash on startup)

[JS]

I would say that there is still a problem with debian packaging in that it 
allows this chromium version

to be installed in a kernel earlier than 2.16, although the result is of no 
value since the new chromium

will not work.


Perhaps for versions 39.0.2171 and higher of chromium, the debian package 
should also require a

kernel version at least 3.16. This would be a rigorous way of implementing the 
requirement that

people running into this problem should upgrade their kernel.


[ I was able to avoid this issue by patching the debian source to avoid this 
check, as it currently

does in chromium.org for this version, and rebuilding on my 32 bit linux with 
the additional flags:

defines+= remove_webcore_debug_symbols=1 \
  component=shared_library \


although at some later point will have to upgrade my kernel to 3.16.]


 
thanks,
--jack


- Original Message -
From: Debian Bug Tracking System 
To: js 
Cc: 
Sent: Friday, December 19, 2014 7:45 PM
Subject: Bug#772471 closed by Michael Gilbert  (Re: 
Bug#772471: chromium crash on startup)

This is an automatic notification regarding your Bug report
which was filed against the chromium package:

#772471: chromium: sandbox issue with nvidia driver

It has been closed by Michael Gilbert .

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 Michael Gilbert 
 by
replying to this email.


-- 
772471: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772471
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problemsOn Thu, Dec 18, 2014 at 8:35 AM, JS 
wrote:
> It was caused by including a check for error codes for non-existent system 
> calls that is not in chromium; see below. This issue is in the debian 3.14 
> kernel and has been fixed in the 3.16 kernel.

Thanks a bunch for digging into this!

So the moral of the story is that chromium won't work on kernels
patched for CVE-2014-4508 and don't include a particular regression
bugfix.  The debian 3.16 and newer kernels are known to include that
bugfix, so users running into this problem should start there.

Best wishes,
Mike
Package: chromium
Version: 39.0.2171.71-2
Severity: important

Dear Maintainer,

=
After upgrade to chromium:i386 39.0.2171.71-2 from chromium:i386 
38.0.2125.101-1,
chromium now crashes every time on startup with the error:
 FATAL:sandbox_bpf.cc(502)] Check failed: -1 == rv (-1 vs. 354)

Note that google-chrome-stable 39.0.2171.71-1  works correctly on the same 
computer.

I am also using the proprietary nvidia driver 340.46-1, which has been 
mentioned in
some chromium threads (see references in code.google.com bug report below), 
although
the 38.0.2125.101 chromium worked fine with this nvidia driver.

submitted chromium bug report:
http://code.google.com/p/chromium/issues/detail?id=439795&thanks=439795&ts=1417965276

=


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

Kernel: Linux 3.14-1-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages chromium depends on:
...


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

Bug#772471: chromium crash on startup

[JS]

The full cause of this chromium crash on 32 bit linux (while the corresponding 
google-chrome-stable version worked fine) was found as issue 439795 on 
https://code.google.com/p/chromium/

It was caused by including a check for error codes for non-existent system 
calls that is not in chromium; see below. This issue is in the debian 3.14 
kernel and has been fixed in the 3.16 kernel.

The full details are in the link below and comment 50 (below) summarizes the 
issue.

thanks,
--jack

https://code.google.com/p/chromium/issues/detail?can=2&start=0#=100&q=&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=439795

#50 ric...@chromium.org 
Hm, I'm not sure why chromium 39.0.2171.71 would include the new syscall check. 
From what what I can tell, that version does not have the check for the seccomp 
syscall: 
https://chromium.googlesource.com/chromium/src.git/+/39.0.2171.71/sandbox/linux/seccomp-bpf/sandbox_bpf.cc

Compare that to 
https://chromium.googlesource.com/chromium/src.git/+/master/sandbox/linux/seccomp-bpf/sandbox_bpf.cc,
 which has the KernelSupportsSeccompTsync function.

You'd probably need to check with whoever built the package you're using to 
figure out how it managed to include that code.


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

Bug#772471: chromium crash on startup

[JS]

Thanks for the quick reply. As you saw, I've also submitted this issue to 
  
http://code.google.com/p/chromium/issues/detail?id=439795&thanks=439795&ts=1417965276

I need the hardware acceleration that is provided by the nvidia driver so 
couldn't lose that

just to use a new version of chromium.

At some point I'll upgrade the kernel but this is a significant issue when 
using the nvidia driver;
if this problem continues until then and is solved by the kernel upgrade, I'll 
update the bug.

I think there are two issues to consider:
  1. this problem did not arise with chromium 38.0.2125.101-2, to which I have 
now reverted

  2. this problem does not arise with google-chrome-stable 39.0.2171.71-1, the 
same version
  as the chromium in this bug report.

These two issues indicate that related software works with the nvidia driver 
and kernel 3.14,
so more likely is caused by changes that are specific to just this new version 
of chromium.

thanks,
--jack





From: Michael Gilbert 
To: 772...@bugs.debian.org; 772471-submit...@bugs.debian.org 
Sent: Sunday, December 7, 2014 6:14 PM
Subject: Bug#772471: chromium crash on startup


control: tag -1 moreinfo
control: severity -1 minor
control: retitle -1 chromium: sandbox issue with nvidia driver

> Kernel: Linux 3.14-1-686-pae (SMP w/6 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
> Shell: /bin/sh linked to /bin/dash

Not sure if it matters, but your kernel is quite out of date.  jessie
currently has 3.16.0-4, so you could try updating.

Also, since this was with the proprietary driver please try nouveau instead.

Best wishes,
Mike


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

Bug#772471: chromium crash on startup

[JS]

Thanks for the quick reply. As you saw, I've also submitted this issue to   
http://code.google.com/p/chromium/issues/detail?id=439795&thanks=439795&ts=1417965276
I need the hardware acceleration that is provided by the nvidia driver so 
couldn't lose that
just to use a new version of chromium.
At some point I'll upgrade the kernel but this is a significant issue when 
using the nvidia driver;if this problem continues until then and is solved by 
the kernel upgrade, I'll update the bug.
I think there are two issues to consider:  1. this problem did not arise with 
chromium 38.0.2125.101-2, to which I have now reverted
  2. this problem does not arise with google-chrome-stable 39.0.2171.71-1, the 
same version      as the chromium in this bug report.
These two issues indicate that related software works with the nvidia driver 
and kernel 3.14,so more likely is caused by changes that are specific to just 
this new version of chromium.
thanks,--jack
  From: Michael Gilbert 
 To: 772...@bugs.debian.org; 772471-submit...@bugs.debian.org 
 Sent: Sunday, December 7, 2014 6:14 PM
 Subject: Bug#772471: chromium crash on startup
   
control: tag -1 moreinfo
control: severity -1 minor
control: retitle -1 chromium: sandbox issue with nvidia driver

> Kernel: Linux 3.14-1-686-pae (SMP w/6 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
> Shell: /bin/sh linked to /bin/dash

Not sure if it matters, but your kernel is quite out of date.  jessie
currently has 3.16.0-4, so you could try updating.

Also, since this was with the proprietary driver please try nouveau instead.

Best wishes,
Mike


  

Bug#772471: chromium crash on startup with error: FATAL:sandbox_bpf.cc(502)] Check failed: -1 == rv (-1 vs. 354)

[js]

Package: chromium
Version: 39.0.2171.71-2
Severity: important

Dear Maintainer,

=
After upgrade to chromium:i386 39.0.2171.71-2 from chromium:i386 
38.0.2125.101-1,
chromium now crashes every time on startup with the error:
 FATAL:sandbox_bpf.cc(502)] Check failed: -1 == rv (-1 vs. 354)

Note that google-chrome-stable 39.0.2171.71-1  works correctly on the same 
computer.

I am also using the proprietary nvidia driver 340.46-1, which has been 
mentioned in
some chromium threads (see references in code.google.com bug report below), 
although
the 38.0.2125.101 chromium worked fine with this nvidia driver.

submitted chromium bug report:
 
http://code.google.com/p/chromium/issues/detail?id=439795&thanks=439795&ts=1417965276

=


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

Kernel: Linux 3.14-1-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages chromium depends on:
ii  libasound2   1.0.28-1
ii  libc62.19-13
ii  libcairo21.14.0-2.1
ii  libcap2  1:2.24-6
ii  libcups2 1.7.5-5
ii  libdbus-1-3  1.8.12-1
ii  libexpat12.1.0-6
ii  libfontconfig1   2.11.0-6.1
ii  libfreetype6 2.5.2-1
ii  libgcc1  1:4.9.1-1
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.0-1
ii  libgnome-keyring03.12.0-1
ii  libgtk2.0-0  2.24.25-1
ii  libharfbuzz0b0.9.35-1
ii  libjpeg62-turbo  1:1.3.1-10
ii  libnspr4 2:4.10.7-1
ii  libnspr4-0d  2:4.10.7-1
ii  libnss3  2:3.17.2-1
ii  libpango-1.0-0   1.36.8-2
ii  libpangocairo-1.0-0  1.36.8-2
ii  libpci3  1:3.2.1-1
ii  libspeechd2  0.8-5
ii  libspeex11.2~rc1.2-1
ii  libsrtp0 1.4.5~20130609~dfsg-1
ii  libstdc++6   4.9.1-1
ii  libudev1 204-6
ii  libx11-6 2:1.6.2-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1
ii  libxdamage1  1:1.1.4-1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-1
ii  libxi6   2:1.7.4-1
ii  libxml2  2.9.1+dfsg1-3
ii  libxrandr2   2:1.4.2-1
ii  libxrender1  1:0.9.8-1
ii  libxslt1.1   1.1.28-2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1
ii  x11-utils7.7+2
ii  xdg-utils1.1.0~rc1+git20111210-7.1

chromium recommends no packages.

Versions of packages chromium suggests:
ii  chromium-inspector  39.0.2171.71-2
ii  chromium-l10n   39.0.2171.71-2

-- Configuration Files:
/etc/chromium.d/README changed:


-- 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#767659: evince 3.14.1-1 gets undefined symbol with libpoppler46:i386 earlier than 0.26.5-2

[js]

Package: evince
Version: 3.14.1-1
Severity: normal

Dear Maintainer,


I just upgraded evince from 3.14.0-2 to 3.14.1-1:
   2014-11-01 12:51:26 upgrade evince:i386 3.14.0-2 3.14.1-1

and consistently got the same error about an undefined symbol in 
libpoppler-glib.so.8 which made it unusable:

=> evince js-paper.pdf

(evince:6432): Gtk-WARNING **: Theme parsing error: gtk.css:102:18: Not 
using units is deprecated. Assuming 'px'.

(evince:6432): Gtk-WARNING **: Theme parsing error: gtk.css:102:20: Not 
using units is deprecated. Assuming 'px'.

(evince:6432): EvinceDocument-WARNING **: 
/usr/lib/i386-linux-gnu/libpoppler-glib.so.8: undefined symbol: 
_ZN7GfxFont16getAlternateNameEPKc
Segmentation fault

The problem was fixed by manually upgrading libpoppler46 from a minor version:
2014-11-01 14:15:30 upgrade libpoppler46:i386 0.26.5-1 0.26.5-2

Perhaps this library is now needed as a dependency for evince 3.14.1-1 to 
install properly?




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

Kernel: Linux 3.14-1-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages evince depends on:
ii  evince-common  3.14.1-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-1
ii  libcairo-gobject2  1.12.16-2
ii  libcairo2  1.12.16-5
ii  libevdocument3-4   3.14.1-1
ii  libevview3-3   3.14.1-1
ii  libgdk-pixbuf2.0-0 2.31.1-2+b1
ii  libglib2.0-0   2.42.0-1
ii  libgtk-3-0 3.14.3-1
ii  libnautilus-extension1a3.14.0-1
ii  libpango-1.0-0 1.36.8-2
ii  libpangocairo-1.0-01.36.8-2
ii  libsecret-1-0  0.18-1
ii  libxml22.9.1+dfsg1-3
ii  shared-mime-info   1.3-1
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages evince recommends:
ii  dbus-x11  1.8.8-1+b1
ii  gvfs  1.22.1-1

Versions of packages evince suggests:
ii  nautilus  3.14.0-1
ii  poppler-data  0.4.7-1
pn  unrar 

-- 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#763821: flightgear: also found in 3.0.0-3+b1

[js]

Package: flightgear
Followup-For: Bug #763821

Dear Maintainer,

=
I have found the same bug in the latest flightgear_3.0.0-3+b1.

The fix for me was the same:
=> export OSG_LIBRARY_PATH=/usr/lib/i386-linux-gnu
=> fgfs --aircraft=f16 ...

The export OSG_LIBRARY_PATH was not needed with version 3.0.0-2

Here is the stack trace of the crash:
...
failed to load effect texture file 
/usr/share/games/flightgear/Textures/Runway/rwy-reflect.png
failed to load effect texture file 
/usr/share/games/flightgear/Textures/Runway/rwy-normalmap.png
failed to load effect texture file 
/usr/share/games/flightgear/Aircraft/Generic/Effects/Rainbow.png
failed to load effect texture file 
/usr/share/games/flightgear/Aircraft/Generic/Effects/FresnelLookUp.png
failed to load effect texture file 
/usr/share/games/flightgear/Textures.high/Runway/pa_1r.png
failed to load effect texture file 
/usr/share/games/flightgear/Textures.high/Runway/pa_1r.png
failed to load effect texture file 
/usr/share/games/flightgear/Textures.high/Runway/pa_1r.png

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xac35ab40 (LWP 3620)]
_dl_map_object (loader=loader@entry=0xb78c82d8, name=name@entry=0xa8fed794 
"osgPlugins-3.2.1/osgdb_png.so", type=type@entry=2, 
trace_mode=trace_mode@entry=0, 
mode=mode@entry=-1879047935, nsid=0) at dl-load.c:2333
2333dl-load.c: No such file or directory.
(gdb) bt
#0  _dl_map_object (loader=loader@entry=0xb78c82d8, name=name@entry=0xa8fed794 
"osgPlugins-3.2.1/osgdb_png.so", type=type@entry=2, 
trace_mode=trace_mode@entry=0, mode=mode@entry=-1879047935, nsid=0) at 
dl-load.c:2333
#1  0xb7ff17b6 in dl_open_worker (a=0xac35872c) at dl-open.c:235
#2  0xb7fed756 in _dl_catch_error (objname=objname@entry=0xac358724, 
errstring=errstring@entry=0xac358728, mallocedp=mallocedp@entry=0xac358723, 
operate=operate@entry=0xb7ff16f0 , 
args=args@entry=0xac35872c) at dl-error.c:187
#3  0xb7ff11e4 in _dl_open (file=0xa8fed794 "osgPlugins-3.2.1/osgdb_png.so", 
mode=-2147483391, 
caller_dlopen=0xb77b0a10 
, 
nsid=, argc=1, argv=0xb2b4, env=0xb2bc)
at dl-open.c:661
#4  0xb6949cbc in dlopen_doit (a=0xac3588e0) at dlopen.c:66
#5  0xb7fed756 in _dl_catch_error (objname=0xab20164c, errstring=0xab201650, 
mallocedp=0xab201648, operate=0xb6949c30 , args=0xac3588e0)
at dl-error.c:187
#6  0xb694a37c in _dlerror_run (operate=operate@entry=0xb6949c30 , 
args=args@entry=0xac3588e0) at dlerror.c:163
#7  0xb6949d71 in __dlopen (file=0xa8fed794 "osgPlugins-3.2.1/osgdb_png.so", 
mode=257) at dlopen.c:87
#8  0xb77b0a10 in osgDB::DynamicLibrary::getLibraryHandle(std::string const&) 
() from /usr/lib/i386-linux-gnu/libosgDB.so.100
#9  0xb77b101b in osgDB::DynamicLibrary::loadLibrary(std::string const&) () 
from /usr/lib/i386-linux-gnu/libosgDB.so.100
#10 0xb77dcf72 in osgDB::Registry::loadLibrary(std::string const&) () from 
/usr/lib/i386-linux-gnu/libosgDB.so.100
#11 0xb77e02dc in osgDB::Registry::read(osgDB::Registry::ReadFunctor const&) () 
from /usr/lib/i386-linux-gnu/libosgDB.so.100
#12 0xb77e10ca in 
osgDB::Registry::readImplementation(osgDB::Registry::ReadFunctor const&, 
osgDB::Options::CacheHintOptions) ()
   from /usr/lib/i386-linux-gnu/libosgDB.so.100
#13 0xb77e193a in osgDB::Registry::readImageImplementation(std::string const&, 
osgDB::Options const*) () from /usr/lib/i386-linux-gnu/libosgDB.so.100
#14 0xb7c7150a in simgear::ModelRegistry::readImage (this=0x8b881e8, 
fileName="/usr/share/games/flightgear/Textures/Terrain/void.png", opt=0x9ddcde0)
at 
/build/simgear-KLiVVU/simgear-3.0.0/simgear/scene/model/ModelRegistry.cxx:199
#15 0xb77d5e96 in osgDB::readImageFile(std::string const&, osgDB::Options 
const*) () from /usr/lib/i386-linux-gnu/libosgDB.so.100
#16 0xb7c2fc59 in simgear::(anonymous namespace)::setAttrs (attrs=..., 
tex=0xa8d7ef28, options=0x9ddcde0)
at 
/build/simgear-KLiVVU/simgear-3.0.0/simgear/scene/material/TextureBuilder.cxx:244
#17 0xb7c40d48 in simgear::TexBuilder::build (this=0x8b86d80, 
effect=0x9e37df0, pass=0xa8d7ec00, props=0x9e55548, options=0x9ddcde0)
at 
/build/simgear-KLiVVU/simgear-3.0.0/simgear/scene/material/TextureBuilder.cxx:306
#18 0xb7c300b7 in buildFromType (options=0x9ddcde0, props=0x9e55548, type="2d", 
pass=0xa8d7ec00, effect=0x9e37df0)
at 
/build/simgear-KLiVVU/simgear-3.0.0/simgear/scene/material/EffectBuilder.hxx:69
#19 simgear::TextureBuilder::buildFromType (effect=0x9e37df0, pass=0xa8d7ec00, 
type="2d", props=0x9e55548, options=0x9ddcde0)
at 
/build/simgear-KLiVVU/simgear-3.0.0/simgear/scene/material/TextureBuilder.cxx:66
#20 0xb7c32d69 in simgear::TextureUnitBuilder::buildAttribute (this=0x8b844a8, 
effect=0x9e37df0, pass=0xa8d7ec00, prop=0x9e55548, options=0x9ddcde0)
at 
/build/simgear-KLiVVU/simgear-3.0.0/simgear/scene/material/TextureBuilder.cxx:133
#21 0xb7c073b0 in simgear::buildPass (effect=0x9e37df0, tniq=0xa8dee7b0, 
prop=0x9e53f90, options=0x9dd

Bug#725997: #725997 - alacarte: config fails with error: alacarte depends on python:any (>= 2.6.6-7~)

[JS]

Pedro,
I've checked my dpkg logs and this issue did not come up with either 
alacarte_3.10.0-1 or alacarte_3.11.91-1

Both installed fine from the repository and I can see they both have dependency 
on python:any instead of python;
maybe that was the problem.

I should have followed this up by posting to the bug so it could be closed, 
very sorry.
 thanks,
  Jack 
  From: Pedro Beja 
 To: jsh...@yahoo.com 
Cc: 725...@bugs.debian.org 
 Sent: Saturday, October 11, 2014 12:26 PM
 Subject: RE: #725997 - alacarte: config fails with error: alacarte depends on 
python:any (>= 2.6.6-7~)
   
Hey Jack,
Could you please still reproduce this issue with newer alacarte version like 
3.11.91-1 ?
it still depends on python (>= 2.6.6-3~) but I can't see your issue here.
thanksregardsalthaser


  

Bug#684580: SIGSEGV in torsocks 2.0.0-1

[JS]

I apologize: I opened the new bug as requested in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760075
but seemed to have responded only to the original emails.


 
thanks,
--jack


- Original Message -
From: intrigeri 
To: 684...@bugs.debian.org; 761...@bugs.debian.org
Cc: JS ; David Goulet 
Sent: Wednesday, September 10, 2014 4:58 PM
Subject: Re: Bug#684580: SIGSEGV in torsocks 2.0.0-1

Hi,

intrigeri wrote (30 Aug 2014 20:18:33 GMT) :
> JS, may you please file a separate bug?

I have done it myself, eventually: #761120. Please keep further
discussion on that new bug, instead of the old #684580 one, that was
fixed in torsocks 2.0. Thanks!




Cheers,
--
intrigeri


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

Bug#684580: SIGSEGV in torsocks 2.0.0-1

[JS]

David,

I've attached text files with the bt full for midori and chromium.

 
thanks,
--jack


- Original Message -
From: David Goulet 
To: JS 
Cc: intrigeri ; "684...@bugs.debian.org" 
<684...@bugs.debian.org>
Sent: Wednesday, September 3, 2014 10:12 AM
Subject: Re: Bug#684580: SIGSEGV in torsocks 2.0.0-1

On 03 Sep (07:09:53), JS wrote:
> David,
> 
> Thanks for looking at this.
> 
> 
> I've never had a problem running midori with torsocks 1.3, so these 
> segmentation faults are new with 2.0.0.
> After reverting to 1.3, midori and iceweasel work correctly with torsocks.
> 
> Is it possible the problem is related to my version of libc6:
> Versions of packages torsocks depends on:
> ii  libc6  2.19-1
> 
> while the newest version is libc6 2.19-9 in jessie?

It's possible but the stacktrace you provided clearly shows torsocks as
the issue so I'm still puzzled.

Is it possible you can provide the full backtrace of the coredump?

Use "bt full" which will help me spot the callsite that segfaults in
tsocks_close().




> 
> thanks,
> --jack
> 
> 
> - Original Message -
> From: David Goulet 
> To: intrigeri 
> Cc: JS ; 684...@bugs.debian.org
> Sent: Wednesday, September 3, 2014 9:10 AM
> Subject: Re: Bug#684580: SIGSEGV in torsocks 2.0.0-1
> 
> On 30 Aug (13:18:33), intrigeri wrote:
> > Hi,
> > 
> > JS wrote (30 Aug 2014 14:59:03 GMT) :
> > > I've just upgrade torsocks from 1.3-3 to 2.0.0-1 and have found that
> > > it gets SIGSEGV now
> > 
> > > Below is the backtrace from gdb after running:
> > >  . torsocks on
> > >  midori# but happens with most other apps as well
> > 
> > I've seen a segfault once when running midori in that context (sid, amd64):
> > 
> > [Aug 30 13:12:26] ERROR torsocks[5021]: [recvmsg] Inet socket passing 
> > detected. Aborting everything! A non Tor socket could be used thus leaking 
> > information. (in tsocks_recvmsg() at recv.c:87)
> 
> This implies that torsocks stopped the application completely. I was
> able to reproduce that once with midori. This is normal behaviour for
> now, since the application is about to receive a TCP socket from an
> other process that is most probably NOT connected to the tor network, we
> abort everything.
> 
> Maybe in the future we could simply deny the recvmsg() call and let the
> application handle the error. That could be less "hammer-ish" :).
> 
> > 
> > ... but I cannot reproduce it anymore.
> > 
> > > Perhaps this is a related problem to #684580?
> > 
> > I doubt it, as torsocks 2.x is a complete rewrite.
> > JS, may you please file a separate bug?
> > 
> > David, could you please have a look?
> 
> I've played around with midori for 10 minutes and I got a lot of
> segfaults from libgnutls, libc, libgtk and libsoup. None from
> libtorsocks yet so I can't confirm the stacktrace below :S.
> 
> Cheers!
> 
> 
> 
> David
> 
> > 
> > > Using host libthread_db library 
> > > "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
> > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x in ?? ()
> > > (gdb) bt
> > > #0  0x in ?? ()
> > > #1  0xb7fcd12b in tsocks_close () from /usr/lib/torsocks/libtorsocks.so
> > > #2  0xb7fcd1d4 in close () from /usr/lib/torsocks/libtorsocks.so
> > > #3  0xb46491a6 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > > #4  0xb464973b in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > > #5  0xb462c7c4 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > > #6 0xb7fed86a in call_init (l=0xb46f15a0, argc=argc@entry=1,
> > > argv=argv@entry=0xb1f4, env=env@entry=0xb1fc) at dl-init.c:64
> > > #7  0xb7fed9a4 in call_init (env=0xb1fc, argv=0xb1f4, argc=1, 
> > > l=) at dl-init.c:36
> > > #8  _dl_init (main_map=0xb7fff930, argc=1, argv=0xb1f4, 
> > > env=0xb1fc) at dl-init.c:126
> > > #9  0xb7fdfd3f in _dl_start_user () from /lib/ld-linux.so.2
> > 
> > 
> > > ~ => /bin/ls -lt /usr/lib/i386-linux-gnu/libGL.so.1 
> > > lrwxrwxrwx 1 root root 48 Nov 22 2013 /usr/lib/i386-linux-gnu/libGL.so.1 
> > > ->
> > > /etc/alternatives/glx--libGL.so.1-i386-linux-gnu
> > > ~ => readlink -f /usr/lib/i386-linux-gnu/libGL.so.1 
> > > /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.340.24
> > 
> > Cheers,
> > -- 
> > intrigeri => . torsocks on
Tor mode activated. Every command will be torif

Bug#684580: SIGSEGV in torsocks 2.0.0-1

[JS]

David,

Thanks for looking at this.


I've never had a problem running midori with torsocks 1.3, so these 
segmentation faults are new with 2.0.0.
After reverting to 1.3, midori and iceweasel work correctly with torsocks.

Is it possible the problem is related to my version of libc6:
Versions of packages torsocks depends on:
ii  libc6  2.19-1

while the newest version is libc6 2.19-9 in jessie?

thanks,
--jack


- Original Message -
From: David Goulet 
To: intrigeri 
Cc: JS ; 684...@bugs.debian.org
Sent: Wednesday, September 3, 2014 9:10 AM
Subject: Re: Bug#684580: SIGSEGV in torsocks 2.0.0-1

On 30 Aug (13:18:33), intrigeri wrote:
> Hi,
> 
> JS wrote (30 Aug 2014 14:59:03 GMT) :
> > I've just upgrade torsocks from 1.3-3 to 2.0.0-1 and have found that
> > it gets SIGSEGV now
> 
> > Below is the backtrace from gdb after running:
> >  . torsocks on
> >  midori# but happens with most other apps as well
> 
> I've seen a segfault once when running midori in that context (sid, amd64):
> 
> [Aug 30 13:12:26] ERROR torsocks[5021]: [recvmsg] Inet socket passing 
> detected. Aborting everything! A non Tor socket could be used thus leaking 
> information. (in tsocks_recvmsg() at recv.c:87)

This implies that torsocks stopped the application completely. I was
able to reproduce that once with midori. This is normal behaviour for
now, since the application is about to receive a TCP socket from an
other process that is most probably NOT connected to the tor network, we
abort everything.

Maybe in the future we could simply deny the recvmsg() call and let the
application handle the error. That could be less "hammer-ish" :).

> 
> ... but I cannot reproduce it anymore.
> 
> > Perhaps this is a related problem to #684580?
> 
> I doubt it, as torsocks 2.x is a complete rewrite.
> JS, may you please file a separate bug?
> 
> David, could you please have a look?

I've played around with midori for 10 minutes and I got a lot of
segfaults from libgnutls, libc, libgtk and libsoup. None from
libtorsocks yet so I can't confirm the stacktrace below :S.

Cheers!



David

> 
> > Using host libthread_db library 
> > "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
> 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x in ?? ()
> > (gdb) bt
> > #0  0x in ?? ()
> > #1  0xb7fcd12b in tsocks_close () from /usr/lib/torsocks/libtorsocks.so
> > #2  0xb7fcd1d4 in close () from /usr/lib/torsocks/libtorsocks.so
> > #3  0xb46491a6 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > #4  0xb464973b in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > #5  0xb462c7c4 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
> > #6 0xb7fed86a in call_init (l=0xb46f15a0, argc=argc@entry=1,
> > argv=argv@entry=0xb1f4, env=env@entry=0xb1fc) at dl-init.c:64
> > #7  0xb7fed9a4 in call_init (env=0xb1fc, argv=0xb1f4, argc=1, 
> > l=) at dl-init.c:36
> > #8  _dl_init (main_map=0xb7fff930, argc=1, argv=0xb1f4, env=0xb1fc) 
> > at dl-init.c:126
> > #9  0xb7fdfd3f in _dl_start_user () from /lib/ld-linux.so.2
> 
> 
> > ~ => /bin/ls -lt /usr/lib/i386-linux-gnu/libGL.so.1 
> > lrwxrwxrwx 1 root root 48 Nov 22 2013 /usr/lib/i386-linux-gnu/libGL.so.1 ->
> > /etc/alternatives/glx--libGL.so.1-i386-linux-gnu
> > ~ => readlink -f /usr/lib/i386-linux-gnu/libGL.so.1 
> > /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.340.24
> 
> Cheers,
> -- 
> intrigeri


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

Bug#760075: torsocks: SIGSEGV with torsocks 2.0.0 on some browsers, failure to anonimize others

[JS]

After restoring to torsocks 1.3-3  all the browsers listed in this bug work 
correctly under tor
with the exception of konqueror: it is still not anonymized and gets blocked at 
my firewall.

The behavior of konqueror under tor seems to be long-standing problem that 
existed before torsocks_2.0.0.

thanks,
--jack


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

Bug#760075: torsocks: SIGSEGV with torsocks 2.0.0 on some browsers, failure to anonimize others

[js]

Package: torsocks
Version: 2.0.0-1
Severity: important

Dear Maintainer,

==
I upgraded torsocks from the 1.3.3 to 2.0.0 and it either SIGSEV on some 
browsers
or else fails to anonimize others (in other words, running under tor they cannot
access sites blocked by my firewall)

These are the exact upgrades made:
Inst tor-geoipdb [0.2.4.22-1] (0.2.4.23-1 Debian:testing [all]) []
Inst tor [0.2.4.22-1] (0.2.4.23-1 Debian:testing [i386])
Inst torsocks [1.3-3] (2.0.0-1 Debian:testing [i386])

I retested this by purging torsocks, tor and tor-geipdb and reinstalling
but got the same results:
- midori, iceape, firefox chromium: SIGSEGV; stack trace for midori:
(gdb) exec-file midori
(gdb) r
Starting program: /usr/bin/midori midori
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xb7fcd12b in tsocks_close () from /usr/lib/torsocks/libtorsocks.so
#2  0xb7fcd1d4 in close () from /usr/lib/torsocks/libtorsocks.so
#3  0xb46491a6 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#4  0xb464973b in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#5  0xb462c7c4 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#6  0xb7fed86a in call_init (l=0xb46f15a0, argc=argc@entry=2, 
argv=argv@entry=0xb6c4, env=env@entry=0xb6d0) at dl-init.c:64
#7  0xb7fed9a4 in call_init (env=0xb6d0, argv=0xb6c4, argc=2, 
l=) at dl-init.c:36
#8  _dl_init (main_map=0xb7fff930, argc=2, argv=0xb6c4, env=0xb6d0) 
at dl-init.c:126
#9  0xb7fdfd3f in _dl_start_user () from /lib/ld-linux.so.2

  Note that the libGL library is from the nvidia proprietary driver:
=> readlink -f /usr/lib/i386-linux-gnu/libGL.so.1
   /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.340.24

- konqueror: runs but not anonimously as firewall intercepts requests:
(gdb) exec-file konqueror
(gdb) r
Starting program: /usr/bin/konqueror midori
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[Aug 31 09:01:39] WARNING torsocks[8021]: [syscall] Unsupported syscall 
number 238. Denying the call (in tsocks_syscall() at syscall.c:165)


- firefox: blocks indefinitely on a futex; tail of strace:
futex(0xb7724058, FUTEX_WAKE_PRIVATE, 2147483647) = 0
readlink("/etc/malloc.conf", 0xbfef52ab, 4096) = -1 ENOENT (No such file or 
directory)
time(NULL)  = 1409493059
futex(0x806538c, FUTEX_WAIT_PRIVATE, 2, NULL  C-c C-cProcess 8364 detached
 

Correct behavior was restored with purge followed by:
 apt-get  install torsocks=1.3-3  tor=0.2.4.22-1 tor-geoipdb=0.2.4.22-1

from the repository:
http://snapshot.debian.org/archive/debian/20140727/ testing/main i386 
Packages
==


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

Kernel: Linux 3.14-1-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages torsocks depends on:
ii  libc6  2.19-1

Versions of packages torsocks recommends:
ii  tor  0.2.4.23-1

torsocks 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#684580: SIGSEGV in torsocks 2.0.0-1

[JS]

I've just upgrade torsocks from 1.3-3 to 2.0.0-1 and have found that it gets 
SIGSEGV now

when before it worked fine.


Below is the backtrace from gdb after running:

 . torsocks on

 midori# but happens with most other apps as well


I have used the exact config file as came with the new torsocks 2.0.0-1 package 
and restarted the tor daemon.

Perhaps this is a related problem to #684580?



Using host libthread_db library 
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xb7fcd12b in tsocks_close () from /usr/lib/torsocks/libtorsocks.so
#2  0xb7fcd1d4 in close () from /usr/lib/torsocks/libtorsocks.so
#3  0xb46491a6 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#4  0xb464973b in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#5  0xb462c7c4 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#6  0xb7fed86a in call_init (l=0xb46f15a0, argc=argc@entry=1, 
argv=argv@entry=0xb1f4, env=env@entry=0xb1fc) at dl-init.c:64
#7  0xb7fed9a4 in call_init (env=0xb1fc, argv=0xb1f4, argc=1, 
l=) at dl-init.c:36
#8  _dl_init (main_map=0xb7fff930, argc=1, argv=0xb1f4, env=0xb1fc) at 
dl-init.c:126
#9  0xb7fdfd3f in _dl_start_user () from /lib/ld-linux.so.2


~ => /bin/ls -lt /usr/lib/i386-linux-gnu/libGL.so.1 
lrwxrwxrwx 1 root root 48 Nov 22  2013 /usr/lib/i386-linux-gnu/libGL.so.1 -> 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu
~ => readlink -f /usr/lib/i386-linux-gnu/libGL.so.1 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.340.24

torsocks:
Installed: 2.0.0-1
Candidate: 2.0.0-1
Version table:
*** 2.0.0-1 0
500 http://debian.lcs.mit.edu/debian/ testing/main i386 Packages
100 /var/lib/dpkg/status


2014-08-30 10:25:23 upgrade tor-geoipdb:all 0.2.4.22-1 0.2.4.23-1
2014-08-30 10:25:25 upgrade tor:i386 0.2.4.22-1 0.2.4.23-1
2014-08-30 10:25:28 upgrade torsocks:i386 1.3-3 2.0.0-1
2014-08-30 10:25:32 configure tor:i386 0.2.4.23-1 
2014-08-30 10:25:34 configure tor-geoipdb:all 0.2.4.23-1 
2014-08-30 10:25:34 configure torsocks:i386 2.0.0-1 
2014-08-30 10:25:34 status installed tor-geoipdb:all 0.2.4.23-1
2014-08-30 10:25:34 status installed tor:i386 0.2.4.23-1
2014-08-30 10:25:35 status installed torsocks:i386 2.0.0-1


 
thanks,
--jack

Bug#751334: nvidia-kernel-dkms: after kernel upgrade from 3.2 to 3.14, root ops fail once X is started

[JS]

After an upgrade to linux-image-3.14-1-686-pae version 3.14.12-1  this problem 
has gone away.

It happened every time, without fail, with these versions of linux-image-3.14:

3.14.9-1 , 3.14.7-1, 3.14.4-1


The upgrade that fixed this was part of an apt-get upgrade which updated 500+ 
packages and it's

possible the cause was some other package that was out of date.


The upgrade to the new kernel did not rebuild:

           /lib/modules/3.14-1-686-pae/updates/dkms/nvidia-current.ko


I would recommend closing this bug now.


751334: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751334 


thanks,
--jack

Bug#754739: grub2: no grub menu and system does not boot if connected only with displayport

[js]

Package: grub2
Version: 2.00-22
Severity: normal

Dear Maintainer,


=

When my system is connected to a monitor with both a DVI cable and a dislayport 
cable,
the system boots fine and after the BIOS screen I see the grub menu, can select 
the linux
kernel to use and it boots without issue.

However, if the system is connected to the monitor with only the displayport 
cable but no DVI,
I still see the system BIOS screen after powering up, but then the grub menu no 
longer appears
and the system does not boot. I verified this by checking 
/var/log/{syslog,messages,boot} after
rebooting with the DVI cable inserted.

If the system is connected to the monitor using only an HDMI cable, then again 
I see the BIOS
screens, the GRUB menu is not visible but the system does boot and I can login 
via ssh.

It seems this issue is restricted to using a displayport cable and grub, as 
even the default
kernel in grub.cfg was not booted in this case, although it did boot when using 
only HDMI.

[The system boots into a console without starting X and the console is not 
visible if the
 monitor input is either displayport or HDMI.]

Here is the /etc/default/grub contents even though grub.cfg is attached as well

  # If you change this file, run 'update-grub' afterwards to update
  # /boot/grub/grub.cfg.
  # For full documentation of the options in this file, see:
  #   info -f grub -n 'Simple configuration'
  
  GRUB_DEFAULT=0
  
  GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with 
Linux 3.2.0-4-686-pae"
  GRUB_TIMEOUT=11
  
  GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
  GRUB_CMDLINE_LINUX_DEFAULT="quiet"
  GRUB_CMDLINE_LINUX="splash nomodeset vga=normal loglevel=5"
  GRUB_BACKGROUND=/boot/grub/splash_images/js-active.png
  
  GRUB_GFXMODE=1600x1200x16,1600x1200,800x600x16,800x600,640x480,auto
  GRUB_GFXPAYLOAD_LINUX=text
  
  # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
  GRUB_DISABLE_LINUX_UUID=true
  
=


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 
rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0
/dev/sda3 /boot ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/sda2 /usr1 ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/sdb1 /usr2 ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/sdb2 /usr3 ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-WDC_WD6401AALS-00E3A0_WD-WCATR4206811
(hd1)   /dev/disk/by-id/ata-ST3200820AS_9QE0Q7NG
(hd2)   /dev/disk/by-id/usb-SanDisk_Cruzer_20053551901B39719A31-0:0
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 
3.2.0-4-686-pae"

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
748a1e12-5704-405a-bf96-df29861c7fe0
else
  search --no-floppy --fs-uuid --set=root 748a1e12-5704-405a-bf96-df29861c7fe0
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=1600x1200x16,1600x1200,800x600x16,800x600,640x480,auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='hd0,msdos3'
if [ x$feature_pla

Bug#751334: nvidia-kernel-dkms: after kernel upgrade from 3.2 to 3.14, root ops fail once X is started

[JS]

I'm attaching a copy of /var/log/Xorg.0.log with nvidia and X running on the 
3.2 kernel, which works fine.

One of the odd things in the Xorg log file when this ran on the 3.14 kernel 
were lines like these (they are
not present when running the 3.2 kernel):

/var/log/Xorg.1.log:[ 48327.144] drmOpenDevice: node name is /dev/dri/card0
/var/log/Xorg.1.log:[ 48327.148] drmOpenByBusid: drmOpenMinor returns -1
/var/log/Xorg.1.log:[ 48327.148] drmOpenDevice: node name is /dev/dri/card1
/var/log/Xorg.1.log:[ 48327.152] drmOpenByBusid: drmOpenMinor returns -1
/var/log/Xorg.1.log:[ 48327.152] drmOpenDevice: node name is /dev/dri/card2


All the libdrm libraries in my system were up to date.


thanks,
-jack

Xorg.0.log
Description: Binary data

Bug#749264: No nvidia-driver working (Karsten Malcher)

[JS]

[I missed sending this to the bug 749264 email, sorry]


> I don't know how to create an xorg.conf?
> There where so many changes in the X system an the drivers and as i know it 
> normallyruns without any xorg.conf now.

nvidia-xconfig will create a usable xorg.conf that will include the nvidia 
driver and, in addition, will add other options that can be specified on the 
command line.
Example: nvidia-xconfig --depth=30 --output-xconfig=my-xorg.conf

This xorg.conf will also merge in options that may already be present in your 
existing /etc/X11/xorg.conf

||  Name Version Architecture   Description
i  nvidia-xconfig    331.67-1    i386   X 
configuration tool for non-free NVIDIA drivers


I track the testing distribution, use only the nvidia drivers packaged by 
debian and have no problem at all using OpenGL applications like flightgear. My 
xorg.conf includes outputs from nvidia-xconfig as well as other options I added 
manually.


thanks,
--jack


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

Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

[JS]

One more thing I forgot to mention: I run a weekly backup of /etc, so it you 
think it would be helpful,

I can send you a gzip version of /etc/texmf/fmt.d  from a few days before the 
failed upgrade of texlive-base.


This would be the /etc/texmf/fmt.d that was in place at the time the 
texlive-base upgrade failed.
 
thanks,
--jack



 From: JS 
To: Norbert Preining ; "673...@bugs.debian.org" 
<673...@bugs.debian.org> 
Cc: "jsh...@yahoo.com"  
Sent: Monday, March 24, 2014 7:32 AM
Subject: Re: Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 
from 2013.20140314-1
 


I forgot to mention:


>The file ebcdic.ocp is in texlive-omega, which also defines the
>aleph format. So the only ideas I have is:
>* you had a harddrive problme and parts ofthe installation got missing
>  (-> nothing we can work around or do anything)

I don't think this is likely as I tried this install several times, with the 
same error,
but it worked perfectly when I removed texlive-base and reinstalled from scratch


>* you have yourself removed parts of the installed files
>  (-> nothing we can work around)

This did not happen as I run  debsums --all --changed --generate=missing 
nightly and
can see from the logfile from before the install that no texlive-* packages 
were affected


> * you have changed the confirguration in /etc/texmf/fmt.d/
>  (-> nothing we can work around, that is your
 responsibility)

As above, the fact that debsums did not flag this package shows there were no 
config
changes (+ the fact that I only did an apt-get remove texlive, so the following 
apt-get install
would have asked about overriding config files, which it did not).


The only thing I have done over and above these (excellent) texlive-* packages 
is add a
package I made myself with the Springer-Verlag Latex macros, which I understand
debian cannot package as they provide no copyright information. Perhaps dealing
with this unexpected package caused a problem (although it has never caused a
problem with previous texlive-base upgrades)?

=> dpkg --status svjour
Package: svjour
Status: install ok installed
Priority: extra
Section: tex
Installed-Size: 463
Maintainer: JS 
Architecture: all
Version: 3.1.0-5
Depends: texlive-binaries (>= 2009)
Description: LaTex macros for all Springer journals
Contains all the Springer LaTex macros
ftp://ftp.springer.de/pub/tex/latex/svjour3/
Homepage: 
http://www.springer.com/authors/journal+authors/faq+for+journal+authors?SGWID=0-1725015-0-0-0

This package was installed long ago and caused no problems for any previous 
texlive-base upgrade:
2012-08-12 12:15:33 status installed svjour:all 3.1.0-5

thanks,
--jack



 From: JS 
To: Norbert Preining ; "673...@bugs.debian.org" 
<673...@bugs.debian.org> 
Sent: Monday, March 24, 2014 7:18 AM
Subject: Re: Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 
from 2013.20140314-1
 


Norbert,


Yes, I do have texlive-omega installed; here are a few lines from dpkg.log 
showing it's been

installed before this upgrade was made:


2014-02-03 20:57:28 upgrade texlive-omega:all 2013.20131112-1 2013.20131219-1
2014-02-03 21:08:07 configure texlive-omega:all 2013.20131219-1
 
2014-02-03 21:08:10 status installed texlive-omega:all 2013.20131219-1
2014-02-03 21:08:24 status installed texlive-omega:all 2013.20131219-1
2014-02-06 11:13:31 upgrade texlive-omega:all 2013.20131219-1 2013.20140123-1
2014-02-06 11:16:02 configure texlive-omega:all 2013.20140123-1 
2014-02-06 11:16:05 status installed texlive-omega:all 2013.20140123-1
2014-02-06 11:16:19 status installed texlive-omega:all 2013.20140123-1
2014-03-23 11:03:39 remove texlive-omega:all 2013.20140123-1        <<<<< 
removed only as part of apt-get remove texlive-base to fix
 install
2014-03-23 11:03:39 status installed texlive-omega:all 2013.20140123-1
2014-03-23 11:11:43 install texlive-omega:all 2013.20140123-1 2013.20140314-1
2014-03-23 11:14:37 configure texlive-omega:all 2013.20140314-1 
2014-03-23 11:14:40 status installed texlive-omega:all 2013.20140314-1


 
thanks,
--jack



 From: Norbert Preining 
To: js ; 673...@bugs.debian.org 
Sent: Monday, March 24, 2014 12:00 AM
Subject: Re: Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 
from 2013.20140314-1
 

Hi,

what you reported is a different item, but please wait before opening
a new bug, because 

On Sun, 23 Mar 2014, js wrote:
> Workaround: I ran apt-get remove texlive-base, followed by an apt-get install
> of texlive-base and all the other packages removed because of texlive-base.
> This install from scratch,without a prior version of texlive-base, worked 
> fine.

Well, then it is
 now impossible to reproduce, unless you have
some more information about the former state:
* did you have texlive-omega ins

Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

[JS]

I forgot to mention:


>The file ebcdic.ocp is in texlive-omega, which also defines the
>aleph format. So the only ideas I have is:
>* you had a harddrive problme and parts ofthe installation got missing
>  (-> nothing we can work around or do anything)

I don't think this is likely as I tried this install several times, with the 
same error,
but it worked perfectly when I removed texlive-base and reinstalled from scratch


>* you have yourself removed parts of the installed files
>  (-> nothing we can work around)

This did not happen as I run  debsums --all --changed --generate=missing 
nightly and
can see from the logfile from before the install that no texlive-* packages 
were affected


> * you have changed the confirguration in /etc/texmf/fmt.d/
>  (-> nothing we can work around, that is your responsibility)

As above, the fact that debsums did not flag this package shows there were no 
config
changes (+ the fact that I only did an apt-get remove texlive, so the following 
apt-get install
would have asked about overriding config files, which it did not).


The only thing I have done over and above these (excellent) texlive-* packages 
is add a
package I made myself with the Springer-Verlag Latex macros, which I understand
debian cannot package as they provide no copyright information. Perhaps dealing
with this unexpected package caused a problem (although it has never caused a
problem with previous texlive-base upgrades)?

=> dpkg --status svjour
Package: svjour
Status: install ok installed
Priority: extra
Section: tex
Installed-Size: 463
Maintainer: JS 
Architecture: all
Version: 3.1.0-5
Depends: texlive-binaries (>= 2009)
Description: LaTex macros for all Springer journals
Contains all the Springer LaTex macros
ftp://ftp.springer.de/pub/tex/latex/svjour3/
Homepage: 
http://www.springer.com/authors/journal+authors/faq+for+journal+authors?SGWID=0-1725015-0-0-0

This package was installed long ago and caused no problems for any previous 
texlive-base upgrade:
2012-08-12 12:15:33 status installed svjour:all 3.1.0-5

thanks,
--jack



 From: JS 
To: Norbert Preining ; "673...@bugs.debian.org" 
<673...@bugs.debian.org> 
Sent: Monday, March 24, 2014 7:18 AM
Subject: Re: Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 
from 2013.20140314-1
 


Norbert,


Yes, I do have texlive-omega installed; here are a few lines from dpkg.log 
showing it's been

installed before this upgrade was made:


2014-02-03 20:57:28 upgrade texlive-omega:all 2013.20131112-1 2013.20131219-1
2014-02-03 21:08:07 configure texlive-omega:all 2013.20131219-1 
2014-02-03 21:08:10 status installed texlive-omega:all 2013.20131219-1
2014-02-03 21:08:24 status installed texlive-omega:all 2013.20131219-1
2014-02-06 11:13:31 upgrade texlive-omega:all 2013.20131219-1 2013.20140123-1
2014-02-06 11:16:02 configure texlive-omega:all 2013.20140123-1 
2014-02-06 11:16:05 status installed texlive-omega:all 2013.20140123-1
2014-02-06 11:16:19 status installed texlive-omega:all 2013.20140123-1
2014-03-23 11:03:39 remove texlive-omega:all 2013.20140123-1        <<<<< 
removed only as part of apt-get remove texlive-base to fix
 install
2014-03-23 11:03:39 status installed texlive-omega:all 2013.20140123-1
2014-03-23 11:11:43 install texlive-omega:all 2013.20140123-1 2013.20140314-1
2014-03-23 11:14:37 configure texlive-omega:all 2013.20140314-1 
2014-03-23 11:14:40 status installed texlive-omega:all 2013.20140314-1


 
thanks,
--jack



 From: Norbert Preining 
To: js ; 673...@bugs.debian.org 
Sent: Monday, March 24, 2014 12:00 AM
Subject: Re: Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 
from 2013.20140314-1
 

Hi,

what you reported is a different item, but please wait before opening
a new bug, because 

On Sun, 23 Mar 2014, js wrote:
> Workaround: I ran apt-get remove texlive-base, followed by an apt-get install
> of texlive-base and all the other packages removed because of texlive-base.
> This install from scratch,without a prior version of texlive-base, worked 
> fine.

Well, then it is now impossible to reproduce, unless you have
some more information about the former state:
* did you have texlive-omega installed?
* what was the content of
 /etc/texmf/fmt.d

> I'll include the zipped file /tmp/fmtutil.3YhQeNol  in the next email.

Which barfs at:
kpathsea: Running mkocp ebcdic.ocp
otp2ocp: fatal: File 'ebcdic' not found.

The file ebcdic.ocp is in texlive-omega, which also defines the
aleph format. So the only ideas I have is:
* you had a harddrive problme and parts ofthe installation got missing
  (-> nothing we can work around or do anything)
* you have yourself removed parts of the installed files
  (-> nothing we can work around)
* you have changed the confirguration in /etc/texmf/fmt.d/
  (-> nothing we can work arou

Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

[JS]

Norbert,


Yes, I do have texlive-omega installed; here are a few lines from dpkg.log 
showing it's been

installed before this upgrade was made:


2014-02-03 20:57:28 upgrade texlive-omega:all 2013.20131112-1 2013.20131219-1
2014-02-03 21:08:07 configure texlive-omega:all 2013.20131219-1 
2014-02-03 21:08:10 status installed texlive-omega:all 2013.20131219-1
2014-02-03 21:08:24 status installed texlive-omega:all 2013.20131219-1
2014-02-06 11:13:31 upgrade texlive-omega:all 2013.20131219-1 2013.20140123-1
2014-02-06 11:16:02 configure texlive-omega:all 2013.20140123-1 
2014-02-06 11:16:05 status installed texlive-omega:all 2013.20140123-1
2014-02-06 11:16:19 status installed texlive-omega:all 2013.20140123-1
2014-03-23 11:03:39 remove texlive-omega:all 2013.20140123-1        <<<<< 
removed only as part of apt-get remove texlive-base to fix install
2014-03-23 11:03:39 status installed texlive-omega:all 2013.20140123-1
2014-03-23 11:11:43 install texlive-omega:all 2013.20140123-1 2013.20140314-1
2014-03-23 11:14:37 configure texlive-omega:all 2013.20140314-1 
2014-03-23 11:14:40 status installed texlive-omega:all 2013.20140314-1


 
thanks,
--jack



 From: Norbert Preining 
To: js ; 673...@bugs.debian.org 
Sent: Monday, March 24, 2014 12:00 AM
Subject: Re: Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 
from 2013.20140314-1
 

Hi,

what you reported is a different item, but please wait before opening
a new bug, because 

On Sun, 23 Mar 2014, js wrote:
> Workaround: I ran apt-get remove texlive-base, followed by an apt-get install
> of texlive-base and all the other packages removed because of texlive-base.
> This install from scratch,without a prior version of texlive-base, worked 
> fine.

Well, then it is now impossible to reproduce, unless you have
some more information about the former state:
* did you have texlive-omega installed?
* what was the content of /etc/texmf/fmt.d

> I'll include the zipped file /tmp/fmtutil.3YhQeNol  in the next email.

Which barfs at:
kpathsea: Running mkocp ebcdic.ocp
otp2ocp: fatal: File 'ebcdic' not found.

The file ebcdic.ocp is in texlive-omega, which also defines the
aleph format. So the only ideas I have is:
* you had a harddrive problme and parts ofthe installation got missing
  (-> nothing we can work around or do anything)
* you have yourself removed parts of the installed files
  (-> nothing we can work around)
* you have changed the confirguration in /etc/texmf/fmt.d/
  (-> nothing we can work around, that is your responsibility)

If you cannot give us a recipe to reproduce this error, or more 
information, I would close a new bug.

Thanks for your understanding

Norbert


PREINING, Norbert                              http://www.preining.info
JAIST, Japan                                 TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

[JS]

The zipped file /tmp/fmtutil.3YhQeNol mentioned below is attached.
 
thanks, 
--jack



 From: js 
To: Debian Bug Tracking System <673...@bugs.debian.org> 
Sent: Sunday, March 23, 2014 1:38 PM
Subject: texlive-base: happened with upgrade to 2013.20140123-1 from 
2013.20140314-1
 

Package: texlive-base
Followup-For: Bug #673022

Dear Maintainer,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   * What led up to the situation:
During an upgrade texlive-base:all 2013.20140123-1 2013.20140314-1, I got the
same error as reported in this bug, so that texlive-base, and all packages 
dependent
on it, failed to get configured:

>   Setting up texlive-base (2013.20140314-1) ...
>   mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST... 
>   mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN... 
>   mktexlsr: Updating /var/lib/texmf/ls-R... 
>   mktexlsr: Done.
>   /usr/bin/tl-paper: setting paper size for dvips to letter.
>   /usr/bin/tl-paper: setting paper size for dvipdfmx to letter.
>   /usr/bin/tl-paper: setting paper size for xdvi to letter.
>   /usr/bin/tl-paper: setting paper size for pdftex to letter.
>   Running mktexlsr. This may take some time... done.
>   Building format(s) --all.
>           This may take some time... 
>   fmtutil-sys failed. Output has been stored in
>   /tmp/fmtutil.3YhQeNol
>   Please include this file if you report a bug.

Workaround: I ran apt-get remove texlive-base, followed by an apt-get install
of texlive-base and all the other packages removed because of texlive-base.
This install from scratch,without a prior version of texlive-base, worked fine.


I'll include the zipped file /tmp/fmtutil.3YhQeNol  in the next email.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
    (pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
List of ls-R files

4 -rw-r--r-- 1 root root 2969 Mar 23 11:15 /var/lib/texmf/ls-R
4 -rw-rw-r-- 1 root staff 80 Nov 28 12:26 /usr/local/share/texmf/ls-R
4 -rw-r--r-- 1 root root 80 Mar 23 11:15 /usr/share/texlive/texmf/ls-R
##
Config files
4 -rw-r--r-- 1 root root 1656 Mar 23 11:15 /etc/texmf/web2c/texmf.cnf
12 -rw-r--r-- 1 root root 9185 Mar 23 11:15 /var/lib/texmf/web2c/fmtutil.cnf
0 lrwxrwxrwx 1 root root 32 Mar 14 00:52 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
12 -rw-r--r-- 1 root root 11141 Mar 23 11:15 
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
4 -rw-r--r-- 1 root root  283 Jun 25  2011 mktex.cnf
4 -rw-r--r-- 1 root root 1656 Mar 23 11:15 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
d588a08518f705d06ac262acd78f2bc4  /etc/texmf/texmf.d/20xmltex.cnf
8e901c9e6562b73e4ba4d1b4e603412f  /etc/texmf/texmf.d/30ptex.bak
055e06548bac99958d8ab2dd1248f2b4  /etc/texmf/texmf.d/80tex4ht.cnf
1df66bc319cec731e202eaf39f5d85e1  /etc/texmf/texmf.d/96JadeTeX.cnf

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

Bug#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

[js]

Package: texlive-base
Followup-For: Bug #673022

Dear Maintainer,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   * What led up to the situation:
During an upgrade texlive-base:all 2013.20140123-1 2013.20140314-1, I got the
same error as reported in this bug, so that texlive-base, and all packages 
dependent
on it, failed to get configured:

>   Setting up texlive-base (2013.20140314-1) ...
>   mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST... 
>   mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN... 
>   mktexlsr: Updating /var/lib/texmf/ls-R... 
>   mktexlsr: Done.
>   /usr/bin/tl-paper: setting paper size for dvips to letter.
>   /usr/bin/tl-paper: setting paper size for dvipdfmx to letter.
>   /usr/bin/tl-paper: setting paper size for xdvi to letter.
>   /usr/bin/tl-paper: setting paper size for pdftex to letter.
>   Running mktexlsr. This may take some time... done.
>   Building format(s) --all.
>   This may take some time... 
>   fmtutil-sys failed. Output has been stored in
>   /tmp/fmtutil.3YhQeNol
>   Please include this file if you report a bug.

Workaround: I ran apt-get remove texlive-base, followed by an apt-get install
of texlive-base and all the other packages removed because of texlive-base.
This install from scratch,without a prior version of texlive-base, worked fine.


I'll include the zipped file /tmp/fmtutil.3YhQeNol  in the next email.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

4 -rw-r--r-- 1 root root 2969 Mar 23 11:15 /var/lib/texmf/ls-R
4 -rw-rw-r-- 1 root staff 80 Nov 28 12:26 /usr/local/share/texmf/ls-R
4 -rw-r--r-- 1 root root 80 Mar 23 11:15 /usr/share/texlive/texmf/ls-R
##
 Config files
4 -rw-r--r-- 1 root root 1656 Mar 23 11:15 /etc/texmf/web2c/texmf.cnf
12 -rw-r--r-- 1 root root 9185 Mar 23 11:15 /var/lib/texmf/web2c/fmtutil.cnf
0 lrwxrwxrwx 1 root root 32 Mar 14 00:52 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
12 -rw-r--r-- 1 root root 11141 Mar 23 11:15 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
4 -rw-r--r-- 1 root root  283 Jun 25  2011 mktex.cnf
4 -rw-r--r-- 1 root root 1656 Mar 23 11:15 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
d588a08518f705d06ac262acd78f2bc4  /etc/texmf/texmf.d/20xmltex.cnf
8e901c9e6562b73e4ba4d1b4e603412f  /etc/texmf/texmf.d/30ptex.bak
055e06548bac99958d8ab2dd1248f2b4  /etc/texmf/texmf.d/80tex4ht.cnf
1df66bc319cec731e202eaf39f5d85e1  /etc/texmf/texmf.d/96JadeTeX.cnf

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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  dpkg   1.17.6
ii  libpaper-utils 1.1.24+nmu2
ii  luatex 0.76.0-3
ii  tex-common 4.04
ii  texlive-binaries 

Bug#742430: libgdk-pixbuf2.0-0:i386: segmentation fault when upgrading libgdk-pixbuf2.0-0:i386

[js]

Package: libgdk-pixbuf2.0-0
Version: 2.30.6-1
Severity: normal

Dear Maintainer,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

   * What led up to the situation:
During an upgrade of libgdk-pixbuf2.0.0:
2014-03-23 10:12:36 upgrade libgdk-pixbuf2.0-0:i386 2.28.2-1+b1 2.30.6-1

I saw the following messages about loaders.cache, which had happened on earlier
upgrades of this library and are described in bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625203 :

(gtk-update-icon-cache-3.0:10228): GdkPixbuf-WARNING **: Cannot open pixbuf 
loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loa
ders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > 
/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
Setting up libgdk-pixbuf2.0-common (2.30.6-1) ...
Setting up libgdk-pixbuf2.0-0:i386 (2.30.6-1) ...
Segmentation fault

In the past these errors got resolved towards the end of the install, the 
loaders.cache
was created and icons and images appeared properly when X restarted.

This time the segmentation fault prevented this from happening, although dpkg 
still
reported the status of this package as ^ii, so there was no indication this 
package
was not properly installed.

   * What was the outcome of this action:
All icons and background images in X failed to appear; some applications like 
the
parole music player did not start because they failed to load icons

Workaround: I manually ran:
  gdk-pixbuf-query-loaders > 
/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache

and then did an: apt-get --reinstall install libgdk-pixbuf2.0.0. This fixed the 
problem

In the past, although I did get the warning about loaders.cache, I never had a 
seg fault
and gdk-pixbuf always ended up correctly installed.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgdk-pixbuf2.0-0:i386 depends on:
ii  libc62.18-4
ii  libgdk-pixbuf2.0-common  2.30.6-1
ii  libglib2.0-0 2.38.2-5
ii  libjasper1   1.900.1-14
ii  libjpeg8 8d-2
ii  libpng12-0   1.2.50-1
ii  libtiff5 4.0.3-7
ii  libx11-6 2:1.6.2-1
ii  multiarch-support2.18-4

libgdk-pixbuf2.0-0:i386 recommends no packages.

libgdk-pixbuf2.0-0:i386 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#737411: xdg-utils: xdg-screensaver needs to default PATH to standard dirs to avoid excess CPU usage

[js]

Package: xdg-utils
Version: 1.1.0~rc1+git20111210-7
Severity: normal

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I'm using XFCE with the parole media player and noticed that media keys
were exceptionally slow, taking more than 15 seconds to change music tracks,
for example [on a 6 core 3.4Ghz system].  Volume change was instantaneous.

This was traced to the use of xdg-screensaver by parole: my PATH selects
my rm script over /bin/rm and xdg-screensaver was using it every 50 seconds.
Once I ran parole from an environment where /bin:/usr/bin were the first 2
components in PATH, the problem went away and it works fine now.

I recommend that xdg-screensaver set PATH to a default sane option to avoid
being inadvertently overriden by settings in the user environment. Many scripts
in /etc/init.d do this (admittedly not normally running from a user 
environment).

This could easily be done by sourcing a /etc/default/xdg-utils file that
would prepend a default XDG_PRE_PATH=/bin:/usr/bin to the PATH (if XDG_PRE_PATH
is not set). This would make the default behavior of xdg-utils work well by
default, regardless of the user environment, while allowing knowleadgeable
users to override that behavior.

xdg-utils should not depend that users only use alias to override the behavior
of rm in order to perform well.

thanks!

PS: [ii  parole  0.5.4-1]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.21-1
ii  libnet-dbus-perl   1.0.0-2+b1
ii  libx11-protocol-perl   0.56-4
ii  x11-utils  7.7+1
ii  x11-xserver-utils  7.7~3

Versions of packages xdg-utils suggests:
ii  gvfs-bin  1.16.3-1+b2

-- 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#736837: [Pkg-xfce-devel] Bug#736780: parole: add media option to play DVD (instead of entering dvd:// in location)

[JS]

Package: parole
Version: 0.5.4-1
Severity: minor


> The “play Disc” entry should replace the “Insert disc” one when a disc is
> detected. “Insert disc” is greyed here too, but as I don't have an
> optical disc reader it makes sense. I'll try to check why it's greyed
> out for you too.


Thanks, some additional info: the DVD is detected and I do see an icon for it 
on the desktop.

The problem happens whether or not the file system is mounted. Automount mounts 
it as /media/cdrom.


This is the only non-commented line in /etc/auto.misc:

    cd  -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom


Finally, I still view this as a minor issue since the DVDs play fine if I enter 
their location as dvd://,

even though the Insert Disc entry is greyed out in the menu.

 
thanks, 
Jack Shaio



 From: Yves-Alexis Perez 
To: JS  
Cc: "736...@bugs.debian.org" <736...@bugs.debian.org>; Debian Bug Tracking 
System  
Sent: Monday, January 27, 2014 1:12 AM
Subject: Re: [Pkg-xfce-devel] Bug#736780: parole: add media option to play DVD 
(instead of entering dvd:// in location)
 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, Jan 26, 2014 at 03:54:17PM -0800, JS wrote:
> > I guess that's what the “Play disc” menu entry is for.
> 
> With parole-0.5.4, these are  ** all **  the options I see under the Media 
> submenu:
> 
>   Insert Disc  [greyed out, even though the DVD is already inserted]
>
  
> Where is the "Play disc" menu? [I tried the other menu options: Edit,
> View, Audio, Help just for completeness] There are no plugins
> installed in my version.
> 
>  
The “play Disc” entry should replace the “Insert disc” one when a disc is
detected. “Insert disc” is greyed here too, but as I don't have an
optical disc reader it makes sense. I'll try to check why it's greyed
out for you too.

Regards,
- -- 
Yves-Alexis Perez
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

Bug#736780: [Pkg-xfce-devel] Bug#736780: parole: add media option to play DVD (instead of entering dvd:// in location)

[JS]

> I guess that's what the “Play disc” menu entry is for.

With parole-0.5.4, these are  ** all **  the options I see under the Media 
submenu:


  Open

  Open Location

  Open Recent

  Insert Disc  [greyed out, even though the DVD is already inserted]

  Quit

 
Where is the "Play disc" menu? [I tried the other menu options: Edit, View, 
Audio, Help just for completeness] There are no plugins installed in my version.

 
thanks, 
Jack Shaio



 From: Yves-Alexis Perez 
To: js ; 736...@bugs.debian.org 
Cc: Debian Bug Tracking System  
Sent: Sunday, January 26, 2014 5:25 PM
Subject: Re: [Pkg-xfce-devel] Bug#736780: parole: add media option to play DVD 
(instead of entering dvd:// in location)
 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On Sun, Jan 26, 2014 at 03:00:51PM -0500, js wrote:
> Package: parole
> Version: 0.5.4-1
> Severity: minor
> 
> Dear Maintainer,
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> I was unable to play DVDs using parole although there was no problem playing 
> them with
> gnome-mplayer, xine, gxine, totem or xbmc. I have installed:
>     ii  libdvdcss2                     1.2.13-0
> 
> Opening locations such as /dev/dvd did not work and left parole stuck.
> 
> The solution from: http://forum.tinycorelinux.net/index.php?topic=7351.0 , to 
> enter
> the Media -> Open Location as dvd://  worked and parole plays DVDs fine this 
> way.
> 
> This was not obvious and I think it would be easier to use parole for DVDs if 
> there was
> an option to select DVD as xine has, for example.
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
I guess that's what the “Play disc” menu entry is for.

Regards,
- -- 
Yves-Alexis Perez
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCgAGBQJS5YtQAAoJEG3bU/KmdcCl4isIAJZjpqJf4iTTAbGlf+I2+psF
wLMG60N66XlMcrbI2XmnzoppCzFduYnR9fiGe5if+t7ZZJ9mtw88GhpunziVj3d6
I2YFbgtaDei3Tqujt4KM63VTzBxFe6aHEKUi8Tf+eEw5dWimNyot4ughAzYmkKcX
Orv23jEB7FbgwYAdaD4v1B0B8NHs2j3n1RZ29dmrESX/iUfG372DudTkPLjvLMXA
S97eX/66kY2rbvB3pdLs9htwGe12Fy0sSgJSsiykRntUzb72zwqJjQl23lueByKM
nUu+Xj82fyi171oJOxia4f6gAJd/qedkD45uSBP4J/MiZS5d+4/8pGIIgawdA5c=
=legs
-END PGP SIGNATURE-

Bug#736780: parole: add media option to play DVD (instead of entering dvd:// in location)

[js]

Package: parole
Version: 0.5.4-1
Severity: minor

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I was unable to play DVDs using parole although there was no problem playing 
them with
gnome-mplayer, xine, gxine, totem or xbmc. I have installed:
ii  libdvdcss2 1.2.13-0

Opening locations such as /dev/dvd did not work and left parole stuck.

The solution from: http://forum.tinycorelinux.net/index.php?topic=7351.0 , to 
enter
the Media -> Open Location as dvd://  worked and parole plays DVDs fine this 
way.

This was not obvious and I think it would be easier to use parole for DVDs if 
there was
an option to select DVD as xine has, for example.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages parole depends on:
ii  gstreamer0.10-x  0.10.36-1.1
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-97
ii  libcairo21.12.16-2
ii  libdbus-1-3  1.7.10-2
ii  libdbus-glib-1-2 0.100.2-1
ii  libfontconfig1   2.11.0-1
ii  libfreetype6 2.4.9-1.1
ii  libgdk-pixbuf2.0-0   2.28.2-1
ii  libglib2.0-0 2.36.4-1
ii  libgstreamer-plugins-base0.10-0  0.10.36-1.1
ii  libgstreamer0.10-0   0.10.36-1.2
ii  libgtk2.0-0  2.24.22-1
ii  libnotify4   0.7.6-1
ii  libpango-1.0-0   1.36.0-1+b1
ii  libpangocairo-1.0-0  1.36.0-1+b1
ii  libpangoft2-1.0-01.36.0-1+b1
ii  libtagc0 1.9.1-2
ii  libx11-6 2:1.6.2-1
ii  libxfce4ui-1-0   4.10.0-5
ii  libxfce4util64.10.1-1
ii  libxfconf-0-24.10.0-2

parole recommends no packages.

Versions of packages parole suggests:
ii  gnome-codec-install 0.4.7+nmu2
ii  gstreamer0.10-ffmpeg0.10.13-5
ii  gstreamer0.10-plugins-bad   0.10.23-7.1
ii  gstreamer0.10-plugins-ugly  0.10.19-2+b3

-- 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#732137: gnustep-gui-doc: missing .../Gui/ProgrammingManual/manual_toc.html referenced in GNUStep doc index.html

[js]

Package: gnustep-gui-doc
Version: 0.20.0-3
Severity: normal

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I've installed the latest gnustep doc packages:
ii  gnustep-base-doc   1.22.1-4.2
ii  gnustep-core-doc   7.7
ii  gnustep-gui-doc0.20.0-3
ii  gnustep-make-doc   2.6.2-2.1

and found that the index.html page provided by:
gnustep-base-doc: /usr/share/GNUstep/Documentation/index.html

has a link to GUI documentation pages that are not installed by gnustep-gui-doc,
for example (I have installed the GUI part of GNUstep, in addition to the doc 
files above):

The following links will work only if you have installed the GUI portion of 
GNUstep.
GUI Programming Manual  (PDF) 

This links to:

file://localhost/usr/share/GNUstep/Documentation/Developer/Gui/ProgrammingManual/manual_toc.html
which is not installed by the doc packages above. Only two AppKit files are in 
the directory
where the GUI manual_toc.html should be; none of the links in AppKit.html works 
but the pdf is fine.

This link should be the same as the one in gnustep.org:

http://www.gnustep.org/resources/documentation/Developer/Gui/ProgrammingManual/AppKit_toc.html

Other links to the GUI documentation, like "GUI Library API" and "GUI 
Additions", are correctly
linked in the Documentation/index.html

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnustep-gui-doc depends on:
ii  gnustep-common [gnustep-fslayout-fhs]  2.6.2-2.1

gnustep-gui-doc recommends no packages.

gnustep-gui-doc 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#606310: googleearth-package: Creates empty Suggests: on architectures other than amd64

[js]

Package: googleearth-package
Version: 1.1.0
Followup-For: Bug #606310

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
version 1.1.0-1 of googleearth-package still leaves an empty Suggests
fields in the package created, see below.

This is a problem if one puts the googleearth package in a local repository
as then apt will not be able to parse the Packages file and will produce
the following error:

=> apt-get --simulate dist-upgrade > /tmp/junk
E: Problem parsing dependency Suggests
>>> E: Error occurred while processing googleearth (NewVersion2)
E: Problem with MergeList /var/lib/apt/lists/_usr3_Installs_DEB_._Packages
E: The package lists or status file could not be parsed or opened.

Removing googleearth from the local repository and rebuilding the Packages
file fixes this error, so it was caused by googleearth. 

=> dpkg --info googleearth_6.0.3.2197+1.1.0-1_i386.deb 
 new debian package, version 2.0.
 size 34994218 bytes: control archive=14697 bytes.
 352 bytes,10 lines  control  
   47044 bytes,   536 lines  md5sums  
 295 bytes, 6 lines   *  postinst #!/bin/bash
 295 bytes, 6 lines   *  postrm   #!/bin/bash
 Package: googleearth
 Version: 6.0.3.2197+1.1.0-1
 Section: non-free/science
 Priority: optional
 Maintainer: Jack Shaio 
 Architecture: i386
 Depends: fonts-liberation, libfreeimage3, lsb-core, libqtcore4, 
libgl1-mesa-glx, libglu1-mesa 
>>>  Suggests: 
 Description: Google Earth, a 3D map/planet viewer
  Package built with googleearth-package.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages googleearth-package depends on:
ii  bzip2   1.0.6-4
ii  dpkg-dev1.16.12
ii  fakeroot1.18.4-2
ii  file1:5.14-2
ii  wget1.14-2
ii  x11-common  1:7.7+1
ii  x11-utils   7.7~1

googleearth-package recommends no packages.

googleearth-package 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#725997: alacarte: config fails with error: alacarte depends on python:any (>= 2.6.6-7~)

[JS]

The problem was fixed by manually upgrading the package   python:any;  then 
installing both
alacarte  3.9.91-1 and the latest alacarte 3.10.0-1 worked properly, where 
before both had
given this error.

This was confusing because the installed python2.6 is above this version 
already:
ii  python2.6                    2.6.8-1.1        i386
ii  python2.6-dev                2.6.8-1.1        i386
ii  python2.6-doc                2.6.8-1.1        all 
ii  python2.6-examples          2.6.8-1.1        all 
ii  python2.6-minimal            2.6.8-1.1        i386

Perhaps adding a dependency on python:any version 2.7.5-5 or greater would avoid
this installation problem?

thanks, 
--jack 


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

Bug#727859: svn-workbench: dpkg dependency problem on python:any

[js]

Package: svn-workbench
Version: 1.6.8-1
Severity: important

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I tried to upgrade to svn-workbench 1.6.8-1 and got this error:
pkg: dependency problems prevent configuration of svn-workbench:
svn-workbench depends on python:any (>= 2.6.6-7~).

This was confusing because the installed python2.6 is above this version 
already:
ii  python2.62.6.8-1.1i386
ii  python2.6-dev2.6.8-1.1i386
ii  python2.6-doc2.6.8-1.1all 
ii  python2.6-examples   2.6.8-1.1all 
ii  python2.6-minimal2.6.8-1.1i386

This happens even if I purge svn-workbench and install it by itself:
The following NEW packages will be installed:
  svn-workbench
0 upgraded, 1 newly installed, 0 to remove and 1541 not upgraded.
Need to get 0 B/502 kB of archives.
After this operation, 1,453 kB of additional disk space will be used.
Selecting previously unselected package svn-workbench.
(Reading database ... 950678 files and directories currently installed.)
Unpacking svn-workbench (from .../svn-workbench_1.6.8-1_all.deb) ...
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Processing triggers for mime-support ...
dpkg: dependency problems prevent configuration of svn-workbench:
 svn-workbench depends on python:any (>= 2.6.6-7~).

dpkg: error processing svn-workbench (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 svn-workbench
E: Sub-process /usr/bin/dpkg returned an error code (1)

The same issue has been reported for a handful of unrelated packages:
  hplip-data: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724705 
  cloudprint: https://github.com/davesteele/cloudprint-service/issues/2
  alacarte: 
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1162388.html

The problem was fixed by manually upgrading the package python:any; then 
svn-workbench
was properly reconfigured.

Perhaps adding a dependency on python:any version 2.7.5-5 or greater would avoid
this installation problem?

thanks,
--jack
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages svn-workbench depends on:
ii  python-svn   1.7.8-0.1
ii  python-wxgtk2.8  2.8.12.1-7
pn  python:any   

svn-workbench recommends no packages.

svn-workbench 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#725997: alacarte: config fails with error: alacarte depends on python:any (>= 2.6.6-7~)

[js]

Package: alacarte
Version: 3.9.91-1
Severity: normal

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I tried to install alacarte and package configuration failed with this error:
  Processing triggers for man-db ...
  dpkg: dependency problems prevent configuration of alacarte:
   alacarte depends on python:any (>= 2.6.6-7~).
  
  dpkg: error processing alacarte (--configure):
   dependency problems - leaving unconfigured
  Setting up gnome-pkg-tools (0.19.3) ...
  Setting up libcapture-tiny-perl (0.22-1) ...
  Setting up libfile-libmagic-perl (0.99-1+b1) ...
  Setting up libgnome-menu-3-dev (3.8.0-2) ...
  Setting up python-gi-dev (3.8.2-1) ...
  Setting up unp (2.0~pre7+nmu1) ...
  Setting up svn-buildpackage (0.8.5) ...
  Errors were encountered while processing:
   alacarte

However, I downloaded the source for alacarte, rebuilt it on my machine
without any changes at all, and the rebuilt package installed without
any errors using dpkg.

[My sources.list follows the testing distribution rather than a specific
release, hence the reason for Debian Release: 7.0:

  deb http://debian.lcs.mit.edu/debian testing main non-free contrib
  deb-src http://debian.lcs.mit.edu/debian testing main non-free contrib

  deb http://security.debian.org/ testing/updates main contrib non-free
  deb-src http://security.debian.org/ testing/updates main contrib non-free
]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages alacarte depends on:
ii  gir1.2-gdkpixbuf-2.0  2.28.2-1
ii  gir1.2-glib-2.0   1.36.0-2+b1
ii  gir1.2-gmenu-3.0  3.8.0-2
ii  gir1.2-gtk-3.03.8.4-1
ii  gnome-menus   3.8.0-2
ii  python2.7.5-2
ii  python-gi 3.8.2-1

alacarte recommends no packages.

alacarte 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#725219: closed by Rene Engelhard (Re: Bug#725219: libreoffice: apt-get install libreoffice: wants to remove gnome)

[JS]

There was an installed copy of libebook-1.2-13 that caused the problem; thanks 
for pinpointing that one.

Once it was removed and replaced with:
      ii  libebook-1.2-14  3.8.5-2 i386 
 

the problem went away:
=> apt-get --simulate install  libreoffice
Reading package lists... Done
Building dependency tree 
Reading state information... Done
The following packages were automatically installed and are no longer required:
   ...The following packages will be upgraded:
   gnome gnome-core libreoffice libreoffice-base libreoffice-base-core 
libreoffice-calc libreoffice-core libreoffice-draw libreoffice-gnome 
libreoffice-gtk
   libreoffice-impress libreoffice-math libreoffice-writer python-uno
  14 upgraded, 0 newly installed, 0 to remove and 2580 not upgraded.   
<<<<<<<<<<


thanks

P.S. I'm well aware wheezy is stable and jessie is testing. By tracking testing 
instead of a specific release, I'll remain on
       testing even after those releases eventually transition to stable, 
without need to change sources.list


____
From: Rene Engelhard 
To: JS ; 725...@bugs.debian.org 
Sent: Sunday, October 6, 2013 10:12 AM
Subject: Re: Bug#725219: closed by Rene Engelhard  (Re: 
Bug#725219: libreoffice: apt-get install libreoffice: wants to remove gnome)


Hi,

On Sun, Oct 06, 2013 at 06:20:17AM -0700, JS wrote:
>    Your explanation below is based on incorrect assumptions and I enclose

No, it's not. I read your report

>    showing the removal of gnome and gnome-core to show that the problem with
>    libreoffice remains even after every
>    libreoffice related package is at version 1:4.1.1-1/
>    1. My system tracks testing, not wheezy or jessie, so that as those

jessie IS testing. (until it's released)

And you have mix setiup because of this in your initial report:

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


testing doesn't say "7.0", it says "jessie/sid":

$ cat jessie/etc/debian_version
jessie/sid

>    2. I depended on apt-get install libreoffice to update all the libreoffice
>    packages.

Yes, that is wrong. Use dist-upgrade. libreoffice is a dummy package and just
says what it striclyneeds, it doesn't enforce versions unless really needed.

> It missed these, which remained at 1.4.0-3:
>           libreoffice-emailmerge libreoffice-help-en-us libreoffice-ogltrans
>    libreoffice-pdfimport libreoffice-report-builder-bin
>        so I updated them individually just now and you can see only 1.4.1.1
>    libreoffice are present:

Wrong. The list in your original report says:

ii  uno-libs3                       4.1.0-5
ii  ure                             4.1.0-5

Not 4.1.1-1.

>    evolution evolution-data-server evolution-exchange evolution-plugins gnome
>       <<<<<<<<<<<<<<<<
>      gnome-contacts gnome-core libfolks-eds25 task-gnome-desktop            
>         <<<<<<<<<<<<<<<<

That sounds like remains of the evolutionm-data-server transition. The new LO
of course needs the new libebook-1.2-14 which needs a newer 
evoluton-data-server installed
- as the new evolution-data-server conflicts against the old (libebook-1.2-13).

If you did a simply dist-upgrade (or upgrade all affected packages manually)
it will just work. If you manually install packages you easily get into this 
situation.

All dependencies are correct and if you had a clean testing both libreoffice 
and gnome
are perfectly co-installable.

Regards,

Rene


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

Bug#725219: libreoffice: apt-get install libreoffice: wants to remove gnome

[js]

Package: libreoffice
Version: 1:4.1.1-1
Severity: normal

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Since libreoffice 1.4.0 I've noticed that apt-get install libreoffice selects
gnome as a package to remove (gnome is my desktop environment).

apt-get install libreoffice libreoffice-gnome   does not try to remove gnome.

Is there a way to change the dependencies in the libreoffice package so that
installing a new version does not try to remove gnome? That seems unnecessary
since including libreoffice-gnome avoids the problem and uninstalling the
desktop environment just to upgrade this application seems excessive.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libreoffice depends on:
ii  fonts-dejavu2.33+svn2514-3
ii  fonts-sil-gentium-basic 1.1-5
ii  libreoffice-base1:4.1.1-1
ii  libreoffice-calc1:4.1.1-1
ii  libreoffice-core1:4.1.1-1
ii  libreoffice-draw1:4.1.1-1
ii  libreoffice-impress 1:4.1.1-1
ii  libreoffice-java-common 1:4.1.1-1
ii  libreoffice-math1:4.1.1-1
ii  libreoffice-report-builder-bin  1:4.0.3-3
ii  libreoffice-writer  1:4.1.1-1
ii  python-uno  1:4.1.1-1

Versions of packages libreoffice recommends:
ii  fonts-liberation  1.07.2-6
ii  libpaper-utils1.1.24+nmu1

Versions of packages libreoffice suggests:
ii  cups-bsd  1.6.2-10
ii  gcj-4.6-jre [java5-runtime]   4.6.4-2
ii  gcj-4.8-jre [java5-runtime]   4.8.1-2
ii  gcj-jre [java5-runtime]   4:4.6.1-3
pn  gstreamer1.0-ffmpeg   
ii  gstreamer1.0-plugins-bad  1.0.7-1
ii  gstreamer1.0-plugins-base 1.0.9-1
ii  gstreamer1.0-plugins-good 1.0.9-1
ii  gstreamer1.0-plugins-ugly 1.0.9-1
ii  hunspell-sv-se [hunspell-dictionary]  1.51-1
pn  hyphen-hyphenation-patterns   
ii  iceape [iceape-browser]   2.7.12-1
ii  iceape-browser2.7.12-1
ii  icedove   10.0.12-1
ii  iceweasel 17.0.8esr-2
ii  imagemagick   8:6.7.7.10-4
ii  libgl1-mesa-glx [libgl1]  9.1.6-2
ii  libreoffice-gnome 1:4.1.1-1
pn  libreoffice-grammarcheck  
pn  libreoffice-help-4.1  
pn  libreoffice-l10n-4.1  
pn  libreoffice-officebean
ii  libsane   1.0.22-7
ii  libxrender1   1:0.9.6-2
ii  myspell-bg [myspell-dictionary]   4.1-3
ii  myspell-ca [myspell-dictionary]   0.20111230b-4
ii  myspell-cs [myspell-dictionary]   20040229-5.1
ii  myspell-da [myspell-dictionary]   1.6.25-1.1
ii  myspell-de-de [myspell-dictionary]20120607-1
ii  myspell-en-us [myspell-dictionary]1:3.3.0-4
ii  myspell-eo [myspell-dictionary]   2.1.2000.02.25-45
ii  myspell-es [myspell-dictionary]   1.11-4
ii  myspell-et [myspell-dictionary]   1:20030606-20
ii  myspell-fr [myspell-dictionary]   1.4-26
ii  myspell-he [myspell-dictionary]   1.1-2
ii  myspell-hu [myspell-dictionary]   1.2+repack-2
ii  myspell-it [myspell-dictionary]   1:3.3.0-4
ii  myspell-ku [myspell-dictionary]   0.20.0-2
ii  myspell-lt [myspell-dictionary]   1.2.1-3
ii  myspell-lv [myspell-dictionary]   0.9.4-5
ii  myspell-nb [myspell-dictionary]   2.0.10-5.1
ii  myspell-nl [myspell-dictionary]   1:2.10-1
ii  myspell-nn [myspell-dictionary]   2.0.10-5.1
ii  myspell-pl [myspell-dictionary]   20120520-1
ii  myspell-pt-br [myspell-dictionary]20110527-2
ii  myspell-pt-pt [myspell-dictionary]20091013-4
ii  myspell-ru [myspell-dictionary]   0.99g5-18
ii  myspell-sk [myspell-dictionary]   0.5.5a-2.3
ii  myspell-sl [myspell-dictionary]   1.0-5
ii  myspell-uk [myspell-dictionary]   1.6.5-2
ii  mythes-en-us [mythes-thesaurus]   1:3.3.0-3
ii  openclipart-libreoffice   1:0.18+dfsg-14
ii  openjdk-7-jre [java5-runtime] 7u21-2.3.9-5
ii  pstoedit  3.60-2+b1
ii  sun-java6-jre [java5-runtime] 6.26-3
ii  unixodbc  2.2.14p2-5

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.10.2-2
ii  fonts-opensymbol2:102.2+LibO4.0.3-3
ii  libatk1.0-0 2.8.0-2
ii  libboost-date-time1.54.01.54.0-2
ii  libc6   2.17-92
ii  libcairo2   1.12.14-4
ii  libclucene-contribs12.3.3

Bug#722258: closed by Andreas Beckmann (Re: Bug#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives)

[JS]

Thanks Andreas,


I would add that since I did not want to risk upgrading my nvidia drivers from 
their current pinned version,

there was no problem fixing this issue while staying with glx-diversions_0.2.2:


   1. I added a local diversion: 

        local 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


   2. in mesa-diverted, I added a hard link from libGL.so.1.2.0 to libGL.so.1.2


   3. and also a symlink from libGL.so.1 -> libGL.so.1.2


With those manual changes, glx-diversions_0.2.2 can be reinstalled without 
errors and hardware acceleration works again.


Maybe the change to libgl1-mesa-glx could have been avoided if the postinstall 
script added more args to the function:

      validate_diverted_symlink  ...   `dpkg --listfiles libgl1-mesa-glx | grep 
'^/usr/lib' | xargs basename -a`


so that however libgl1-mesa-glx chose to version its libGL.so, they would still 
be found by glx-diversions postinstall.


 
thanks, 
--jack

 




 From: Debian Bug Tracking System 
To: js  
Sent: Tuesday, September 10, 2013 8:30 AM
Subject: Bug#722258 closed by Andreas Beckmann  (Re: 
Bug#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives)
 

This is an automatic notification regarding your Bug report
which was filed against the glx-diversions package:

#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives

It has been closed by Andreas Beckmann .

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 Andreas Beckmann 
 by
replying to this email.


-- 
722258: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722258
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problemsVersion: 0.4.0

On 2013-09-10 13:02, JS wrote:
> Vincent,
> 
> You're right, thank you for pointing this out. I've checked that 
> glx-diversions_0.4.0 does include a libGL.so.1.2.0
> as one of the arguments to validate_diverted_symlink and so will not have 
> this problem.
> 
> I was not able to use this version of glx-diversions as I've kept my version 
> of the nvidia drivers pinned to 304.64-4.
> 
> This bug should be closed as a duplicate that has already been fixed in the 
> latest version.

Closing.

BTW, libgl1-mesa-glx has a fix pending that adds a
  Breaks: glx-diversions (<< 0.4)
so people won't be able to do this broken partial upgrade any more.

Andreas
Package: glx-diversions
Version: 0.2.2
Severity: normal

Dear Maintainer,

I updated libgl1-mesa-glx to version 9.1.6-2 (from 8.0.5-3) and saw that
afterwards /usr/lib/i386-linux-gnu/libGL.so.1 -> libGL.so.1.2.0 instead
of the /etc/alternatives/glx--... that would lead to the nvidia library.

Therefore the hardware acceleration was broken.

I tried purging all the nvidia files and reinstalling but the problem
persists because the glx-alternatives postinst script does a
validate_diverted_symlink() and does a "Restoring diverted libGL.so.1 symlink".
After reinstalling glx-diversions (many attempts), this left libGL.so.1
pointing to the library from libgl1-mesa-glx.

This happened even after I removed all the nvidia packages, manually removed
any remaining diversions for '*glx*' so that only libgl1-mesa-glx was left,
with no diversions.

I would have thought glx-diversions would have left the diversion in place
and tried to leave the symlink pointing to /etc/alternatives.

Manually setting this link to point to /etc/alternatives/glx--... does
restore hardware acceleration but this seems to break whenever another
package is installed, so is not a real workaround.

I have the nvidia drivers pinned to 306.64-4 and therefore glx-diversions
is pinned to 0.2.2 (I understand this is not the latest version).

Here is a typical session from /var/log/apt/term.log showing the problem
(see especially lines marked with >>>):
    Log started: 2013-09-09  09:52:53
    Selecting previously unselected package glx-diversions.
    (Reading database ... (Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 943874 files and directories currently installed.)
    Unpacking glx-diversions (from .../glx-diversions_0.2.2_i386.deb) ...
    Selecting previously unselected package glx-alternative-mesa

Bug#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives

[JS]

Vincent,

You're right, thank you for pointing this out. I've checked that 
glx-diversions_0.4.0 does include a libGL.so.1.2.0
as one of the arguments to validate_diverted_symlink and so will not have this 
problem.

I was not able to use this version of glx-diversions as I've kept my version of 
the nvidia drivers pinned to 304.64-4.

This bug should be closed as a duplicate that has already been fixed in the 
latest version.
 
thanks again,
Jack



 From: Vincent Cheng 
To: JS  
Cc: 722...@bugs.debian.org 
Sent: Tuesday, September 10, 2013 4:54 AM
Subject: Re: Bug#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives
 

On Mon, Sep 9, 2013 at 10:54 AM, JS  wrote:
> I believe this problem comes about because:
>
> libgl1-mesa-glx 8.0.5-3  has the library libGL.so.1.2:
>    => dpkg --contents libgl1-mesa-glx_8.0.5-3_i386.deb
>   drwxr-xr-x root/root 0 2012-12-06 17:23 ./
>   drwxr-xr-x root/root 0 2012-12-06 17:22 ./usr/
>   drwxr-xr-x root/root 0 2012-12-06 17:22 ./usr/lib/
>   drwxr-xr-x root/root 0 2012-12-06 17:22 ./usr/lib/i386-linux-gnu/
>   -rw-r--r-- root/root 363020 2012-12-06 17:22
> ./usr/lib/i386-linux-gnu/libGL.so.1.2   <<<<<
>
> while the newer libgl1-mesa-glx 9.1.6-2 has the library:
>   => dpkg --contents
> /var/cache/apt/archives/libgl1-mesa-glx_9.1.6-2_i386.deb
>   drwxr-xr-x root/root 0 2013-08-12 02:50 ./
>   drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/
>   drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/lib/
>   drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/lib/i386-linux-gnu/
>   -rw-r--r-- root/root 357692 2013-08-12 02:50
> ./usr/lib/i386-linux-gnu/libGL.so.1.2.0 <<<<<
>   drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/share/
>
>
> glx-diversions postinst is checking for a final target of libGL.so.1.2 (not
> libGL.so.1.2.0) so it always
> fails when the newer libgl1-mesa-glx is installed:
>     validate_diverted_symlink /usr/lib${triplet}libGL.so.1
> /usr/lib/mesa-diverted${triplet}libGL.so.1 mesa/libGL.so.1 libGL.so.1.2
>

This sounds like bug #712304 to me, which was fixed as of glx-diversions 0.4.0.

Regards,
Vincent

Bug#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives

[JS]

I believe this problem comes about because:

libgl1-mesa-glx 8.0.5-3  has the library libGL.so.1.2:
   => dpkg --contents libgl1-mesa-glx_8.0.5-3_i386.deb 
  drwxr-xr-x root/root 0 2012-12-06 17:23 ./
  drwxr-xr-x root/root 0 2012-12-06 17:22 ./usr/
  drwxr-xr-x root/root 0 2012-12-06 17:22 ./usr/lib/
  drwxr-xr-x root/root 0 2012-12-06 17:22 ./usr/lib/i386-linux-gnu/
  -rw-r--r-- root/root363020 2012-12-06 17:22 
./usr/lib/i386-linux-gnu/libGL.so.1.2   <


while the newer libgl1-mesa-glx 9.1.6-2 has the library:
  => dpkg --contents /var/cache/apt/archives/libgl1-mesa-glx_9.1.6-2_i386.deb 
  drwxr-xr-x root/root 0 2013-08-12 02:50 ./
  drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/
  drwxr-xr-x root/root 0 2013-08-12 02:50
 ./usr/lib/
  drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/lib/i386-linux-gnu/
  -rw-r--r-- root/root357692 2013-08-12 02:50 
./usr/lib/i386-linux-gnu/libGL.so.1.2.0 <
  drwxr-xr-x root/root 0 2013-08-12 02:50 ./usr/share/



glx-diversions postinst is checking for a final target of libGL.so.1.2 (not 
libGL.so.1.2.0) so it always

fails when the newer libgl1-mesa-glx is installed:
    validate_diverted_symlink /usr/lib${triplet}libGL.so.1 
/usr/lib/mesa-diverted${triplet}libGL.so.1 mesa/libGL.so.1 libGL.so.1.2

Perhaps the postinst script could check only that the link is owned by the 
package libgl1-mesa-glx; here is a piece of the
postinst script showing the problem:

+ owner=libgl1-mesa-glx:i386: /usr/lib/i386-linux-gnu/libGL.so.1       < 
package installing an libGL.so.1
+ [ -L /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 ]
+ [ -z libgl1-mesa-glx:i386: /usr/lib/i386-linux-gnu/libGL.so.1 ]
+ readlink /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
+ link=libGL.so.1.2.0                                                           
             < readlink -f of its libGL.so.1
+ [ -L /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 ]
+ [ libGL.so.1.2.0 = mesa/libGL.so.1 ]
+ [ -L /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 ]
+ [ libGL.so.1.2.0 = libGL.so.1.2 ]
+ [ -L /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 ]
+ [ libGL.so.1.2.0 != libGL.so.1.2 ]





+ echo Removing diverted 'libGL.so.1' symlink with unexpected target 
'libGL.so.1.2.0'.
Removing diverted 'libGL.so.1' symlink
 with unexpected target 'libGL.so.1.2.0'.

Bug#722258: glx-diversions fails libGL.so.1 -> /etc/alternatives

[js]

Package: glx-diversions
Version: 0.2.2
Severity: normal

Dear Maintainer,

I updated libgl1-mesa-glx to version 9.1.6-2 (from 8.0.5-3) and saw that
afterwards /usr/lib/i386-linux-gnu/libGL.so.1 -> libGL.so.1.2.0 instead
of the /etc/alternatives/glx--... that would lead to the nvidia library.

Therefore the hardware acceleration was broken.

I tried purging all the nvidia files and reinstalling but the problem
persists because the glx-alternatives postinst script does a
validate_diverted_symlink() and does a "Restoring diverted libGL.so.1 symlink".
After reinstalling glx-diversions (many attempts), this left libGL.so.1
pointing to the library from libgl1-mesa-glx.

This happened even after I removed all the nvidia packages, manually removed
any remaining diversions for '*glx*' so that only libgl1-mesa-glx was left,
with no diversions.

I would have thought glx-diversions would have left the diversion in place
and tried to leave the symlink pointing to /etc/alternatives.

Manually setting this link to point to /etc/alternatives/glx--... does
restore hardware acceleration but this seems to break whenever another
package is installed, so is not a real workaround.

I have the nvidia drivers pinned to 306.64-4 and therefore glx-diversions
is pinned to 0.2.2 (I understand this is not the latest version).

Here is a typical session from /var/log/apt/term.log showing the problem
(see especially lines marked with >>>):
Log started: 2013-09-09  09:52:53
Selecting previously unselected package glx-diversions.
(Reading database ... (Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 943874 files and directories currently installed.)
Unpacking glx-diversions (from .../glx-diversions_0.2.2_i386.deb) ...
Selecting previously unselected package glx-alternative-mesa.
Unpacking glx-alternative-mesa (from 
.../glx-alternative-mesa_0.2.2_i386.deb) ...
Selecting previously unselected package glx-alternative-nvidia.
Unpacking glx-alternative-nvidia (from 
.../glx-alternative-nvidia_0.2.2_i386.deb) ...
Selecting previously unselected package libgl1-nvidia-alternatives.
Unpacking libgl1-nvidia-alternatives (from 
.../libgl1-nvidia-alternatives_304.64-4_i386.deb) ...
Selecting previously unselected package libglx-nvidia-alternatives.
Unpacking libglx-nvidia-alternatives (from 
.../libglx-nvidia-alternatives_304.64-4_i386.deb) ...
Selecting previously unselected package nvidia-alternative.
Unpacking nvidia-alternative (from 
.../nvidia-alternative_304.64-4_i386.deb) ...
Selecting previously unselected package nvidia-support.
Unpacking nvidia-support (from .../nvidia-support_20120630+3_i386.deb) ...
Selecting previously unselected package libgl1-nvidia-glx:i386.
Unpacking libgl1-nvidia-glx:i386 (from 
.../libgl1-nvidia-glx_304.64-4_i386.deb) ...
Selecting previously unselected package libxvmcnvidia1:i386.
Unpacking libxvmcnvidia1:i386 (from .../libxvmcnvidia1_304.64-4_i386.deb) 
...
Selecting previously unselected package xserver-xorg-video-nvidia.
Unpacking xserver-xorg-video-nvidia (from 
.../xserver-xorg-video-nvidia_304.64-4_i386.deb) ...
Selecting previously unselected package nvidia-vdpau-driver:i386.
Unpacking nvidia-vdpau-driver:i386 (from 
.../nvidia-vdpau-driver_304.64-4_i386.deb) ...
Selecting previously unselected package nvidia-kernel-dkms.
Unpacking nvidia-kernel-dkms (from 
.../nvidia-kernel-dkms_304.64-4_i386.deb) ...
Selecting previously unselected package nvidia-glx.
Unpacking nvidia-glx (from .../nvidia-glx_304.64-4_i386.deb) ...
Selecting previously unselected package nvidia-settings.
Unpacking nvidia-settings (from .../nvidia-settings_304.64-1_i386.deb) ...
Processing triggers for man-db ...
Processing triggers for menu ...
Processing triggers for gnome-menus ...
Processing triggers for mime-support ...
Processing triggers for desktop-file-utils ...
Setting up glx-diversions (0.2.2) ...
No diversion 'diversion of 
/usr/lib/debug/usr/lib/xorg/modules/extensions/libglx.so to 
/usr/lib/mesa-diverted/libglx.so.dbg by glx-diversions', none removed.
No diversion 'diversion of /usr/lib/xorg/modules/extensions/libglx.so to 
/usr/lib/mesa-diverted/libglx.so by glx-diversions', none removed.
Adding 'diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so 
by glx-diversions'
Adding 'diversion of /usr/lib/i386-

Bug#720449: apt-utils 0.9.9.4 needs dependency on libapt-inst1.5 >= 0.9.9.4

[JS]

Below are the dependencies for 3 versions of apt-utils from apt-cache showpkg.


Perhaps for version 0.9.9.4 the first should be: libapt-instl.5 (2 0.9.9) or at 
least some version greater than 0.9.7.7,

which was the one installed on my system when this problem was happening.



Dependencies: 
0.9.9.4 - libapt-inst1.5 (2 0.8.0) libapt-pkg4.12 (2 0.9.9.4) libc6 (2 2.4) 
libdb5.1 (0 (null)) libgcc1 (2 1:4.1.1) libstdc++6 (2 4.4.0) xz-utils (0 
(null)) 
0.9.7.7 - libapt-inst1.5 (2 0.8.0) libapt-pkg4.12 (2 0.8.16~exp9) libc6 (2 2.4) 
libdb5.1 (0 (null)) libgcc1 (2 1:4.1.1) libstdc++6 (2 4.4.0) xz-utils (0 
(null)) 
0.8.15.10 - apt (2 0.8.12) libapt-pkg4.10 (0 (null)) libc6 (2 2.4) libdb5.1 (0 
(null)) libgcc1 (2 1:4.1.1) libstdc++6 (2 4.4.0) 


 
thanks,
--jack

Bug#720449: apt-utils 0.9.9.4 needs dependency on libapt-inst1.5 >= 0.9.9.4

[js]

Package: apt-utils
Version: 0.9.9.4
Severity: normal

Dear Maintainer,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I upgraded apt-utils to version 0.9.9.4 (from version 0.9.8.1) 
and apt-get did not require an upgrade also for libapt-inst1.5 to
version 0.9.9.4. Therefore my version of this library remained at 0.9.7.7.

apt-extracttemplates and apt-ftparchive still worked, but on every package
produced the error:

   E: Could not open file descriptor -1
  debconf: apt-extracttemplates failed: No such file or directory 

although the installs and ftp archives did complete with no error.

I was able to trace this to the method:
 ExtractTar::StartGzip() () from /usr/lib/i386-linux-gnu/libapt-inst.so.1.5

Upgrading libapt-instl to version 0.9.9.4 fixed the problem. The higher
version of this library package should be added to the dependencies for
apt-utils.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt-utils depends on:
ii  libapt-inst1.5  0.9.9.4
ii  libapt-pkg4.12  0.9.9.4
ii  libc6   2.17-92
ii  libdb5.15.1.29-6
ii  libgcc1 1:4.8.1-2
ii  libstdc++6  4.8.1-2

apt-utils recommends no packages.

Versions of packages apt-utils suggests:
ii  xz-utils  5.1.1alpha+20120614-2

-- 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#716876: gnome-session needs to update dependency on libatspi2.0-0:i386 2.5.1-1 2.9.3-1

[js]

Package: gnome-session
Version: 3.4.2.1-4
Severity: important

Dear Maintainer,

After an upgrade of gnome-session:all from 3.4.2.1-3 to 3.4.2.1-4
gnome-session failed to run due to a missing symbol in the shared library 
libatspi.so.0.0.1
provided by libatspi2.0-0.

This was using libatspi2.0-0:i386 2.5.1-1  and apt-get did not bring in a newer 
version
when I installed gnome-session. After manually upgrading libatspi2.0-0 to 
version 2.9.3-1,
the problem went away.

Maybe the gnome-session package should update its dependency on libatspi2.0-0 
to a higher
version than 2.5.1-1.




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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.4.2.1-4
ii  gnome-session-common   3.4.2.1-4
ii  gnome-settings-daemon  3.4.2+git20121218.7c1322-3
ii  gnome-shell3.4.2-10

Versions of packages gnome-session recommends:
ii  gnome-power-manager 3.8.2-1
ii  gnome-session-fallback  3.4.2.1-4

Versions of packages gnome-session suggests:
ii  desktop-base  7.0.3
ii  gnome-keyring 3.4.1-4
ii  gnome-user-guide  3.8.2-1

-- no debconf information


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

Bug#716695: googleearth-package: needs to remove libcurl.so.4 from googleearth

[JS]

In addition to changes in the control files for googleearth-package and the 
googleearthdeb that it generates,
of course fixing the problem requires also that the libcurl.so.4 that comes 
with the googleearth blob be removed
from the package created by googleearth-package.

thanks,
--jack


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

Bug#716695: googleearth-package: needs to remove libcurl.so.4 from googleearth otherwise always get "Invalid HTTP request"

[js]

Package: googleearth-package
Version: 0.7.0
Severity: important

Dear Maintainer,

The googleearth package built includes the libcurl.so.4 shared lib that comes 
with the googleearth blob.

This library now no longer works with the google earth servers and will always 
return "Invalid HTTP Request"
error any time one tries to search for any location.

I have verified that removing this library and installing:
 ii libcurl3:i386  7.31.0-2

solves the problem and allows the googleerth installed via this package to work 
correctly.

My recommendation is for googleearth-package to Recommend: libcurl3 (>= 7.31.0) 
and to build a package that
Requires libcurl3 (>= 7.31.0). I have not tested with earlier versions of 
libcurl to see if they work.




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

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages googleearth-package depends on:
ii  bzip2   1.0.6-1
ii  curl7.31.0-2
ii  dpkg-dev1.16.10
ii  fakeroot1.18.4-2
ii  file1:5.14-2
ii  wget1.14-2
ii  x11-common  1:7.7+1
ii  x11-utils   7.7~1

googleearth-package recommends no packages.

googleearth-package 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#711924: claws-mail: segmentation fault if click on Inbox right after startup while new messages are being read in

[JS]

I made 4 changes that seemed to have improved this and the crash on startup 
rarely happens now,
although there is clearly a difference between clicking on an Inbox item and on 
an item in another folder
upon startup.

In order of importance:

1. the most effective change: ~/.claws-mail/imapcache/localhost//INBOX   
used to be a symlink to a directory in another
    partition on the same physical drive. 

    Changing it to be a regular directory in home directory made startup much 
faster and reduced the crashes.


2. the crashes happened most often after a failed upgrade to dovecot_1:2.1.7-7. 
 I had to edit post-remove scripts manually
    to be able to restore the previous version.

    After purging dovecot and installed the latest 1:2.1.7-7, which now 
succeeded without a problem, seems to have helped
    with claws-mail

3. I updated libproxy0 to the latest version, as you suggested.

4. I upgraded to claws-mail_3.9.2


The problem doesn't appear anymore; I tried claws-mail in a loop 6 times with 
an unread incoming message and got no crash.

thanks for pointing me to libproxy0!
--jack


  => apt-cache policy libproxy0
libproxy0:
  Installed: 0.3.1-4+b1
  Candidate: 0.3.1-6
  Version table:
     0.3.1-6 0
        500 http://debian.lcs.mit.edu/debian/ testing/main i386 Packages
     0.3.1-5.1 0
        500 http://snapshot.debian.org/archive/debian/20130207/ wheezy/main 
i386 Packages
        500 http://snapshot.debian.org/archive/debian/20130110/ wheezy/main 
i386 Packages
     0.3.1-4+b3 0
        500 http://snapshot.debian.org/archive/debian/20120327T225039Z/ 
wheezy/main i386 Packages
 *** 0.3.1-4+b1 0
        100 /var/lib/dpkg/status


        From: Ricardo Mones 
 To: js ; 711...@bugs.debian.org 
 Sent: Tuesday, June 18, 2013 6:26 AM
 Subject: Bug#711924: claws-mail: segmentation fault if click on Inbox right 
after startup while new messages are being read in
   
tags 711924 moreinfo
thanks

  Hi js,

On Mon, Jun 10, 2013 at 11:00:44PM -0400, js wrote:
> Package: claws-mail
> Version: 3.9.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> 
>   When one clicks on any email in the Inbox just after claws-mail starts
> up and there are new emails being read in, claws-mail gets a segmentation
> fault (stack trace below) that looks like:
>     fancy_viewer.c:856:fancy_viewer_create
 
>   Can work around this by waiting several minutes after claws-mail starts
> up before selecting any mail in the Inbox.
>   Note that this problem only happens for mails in
 the Inbox; one can 
> select an email in Trash, Drafts, Sent, etc. immediately after startup 
> without any problem. Only emails in the Inbox cause the segmentation fault.
> 
>   Claws-mail should continue to run without crashing after selecting an 
> email in Inbox right after startup, just as it does when selecting an email
> in the other mail folders just after startup.

  That's very strange, unless all the messages in your inbox are HTML.

  Even more weird that waiting fixes the crash below, unless there's some
process in the background playing.

> 
>   Full stack trace:
>     0xb7fe8329 in dl_new_hash (s=0xd5d003f7 bounds>) at dl-lookup.c:477
>     477    dl-lookup.c: No such file or directory.
>     (gdb) bt
>     #0  0xb7fe8329 in dl_new_hash
 (s=0xd5d003f7 ) at dl-lookup.c:477
>     #1  _dl_lookup_symbol_x (undef_name=0xd5d003f7 bounds>, undef_map=undef_map@entry=0x89d33a0, ref=ref@entry=0xbfffd5e4, 
>         symbol_scope=symbol_scope@entry=0x89d3558, version=0x0, type_class=0, 
>flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:717
>     #2  0xb7fe9fd1 in elf_machine_rel (sym=0xb0ae7738, skip_ifunc=0, 
>reloc_addr_arg=0xab78e000, version=, map=0x89d33a0, 
>reloc=)
>         at ../sysdeps/i386/dl-machine.h:339
>     #3  elf_dynamic_do_Rel (skip_ifunc=0, lazy=, 
>nrelative=, relsize=, reladdr=, 
>map=0x89d33a0) at do-rel.h:137
>     #4  _dl_relocate_object (scope=0x89d3558, reloc_mode=reloc_mode@entry=0, 
>consider_profiling=0, consider_profiling@entry=5) at dl-reloc.c:265
>     #5  0xb7ff1de7 in dl_open_worker (a=a@entry=0xbfffd7ec) at dl-open.c:420
>     #6  0xb7fedb2e in _dl_catch_error (objname=objname@entry=0xbfffd7e4, 
>errstring=errstring@entry=0xbfffd7e8, mallocedp=mallocedp@entry=0xbfffd7e3, 
>         operate=operate@entry=0xb7ff1a00 , 
>args=args@entry=0xbfffd7ec) at dl-error.c:177
>     #7  0xb7ff15d4 in _dl_open (file=0x89d2390 
>"/usr/lib/libproxy/0.3.1/modules/pacrunner_mozjs.so", mode=-2147483646, 
>         caller_dlopen=caller_dlopen@entry=0xaed941ac 
>, nsid=-2, argc=argc@entry=2, 
>argv=argv@entry=0xb484, env=0x83f4690) at dl-open.c:656
>     #8  0xb6cc4cce in dlopen_doit (a=a@entry=0xbfffd9a0) at dlopen.c:66
>     #9  0xb7fedb2e in _dl_catch_error (objname=0x83fbbf4, 
>errstring=0

Bug#702757: googleearth 7 needed to search

[JS]

I noticed that the search function no longer works with 
googleearth_6.0.3.2197+0.7.0-1
and always returns "Invalid HTTP request", although the URL returned, found 
using wireshark,
is valid and can be cut+pasted into a browser.

Using the google-earth-stable_7.1.1.1871-r0  (from earth.google.com) fixed the 
problem and allowed
searches in googleearth to be done again.

So until make-googlearth is upgraded to build the 7.x version of googleearth, 
the resulting package
will have little functionality because it won't be able to search new 
locations. The check for updates
in googleearth 6.x does not indicate that a version 7 is available.

thanks,
--jack


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

Bug#703715: linux-image-3.2.0-4-amd64: random Wheezy freeze

[JS Ubei]

Two more freezes this morning without possibility to switch to console ... And 
yes of course each time I lose data.
I'm tired ... after using debian since many years I'm looking for moving to 
another distro.


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

Bug#711924: claws-mail: segmentation fault if click on Inbox right after startup while new messages are being read in

[js]

Package: claws-mail
Version: 3.9.1-1
Severity: normal

Dear Maintainer,

* What led up to the situation?

  When one clicks on any email in the Inbox just after claws-mail starts up and 
there are new emails being read in,
  claws-mail gets a segmentation fault (stack trace below) that looks like:
fancy_viewer.c:856:fancy_viewer_create
[New Thread 0xad7ffb40 (LWP 31837)]
[New Thread 0xacefeb40 (LWP 31838)]
[New Thread 0xac4ffb40 (LWP 31839)]

Program received signal SIGSEGV, Segmentation fault.

0xb7fe8329 in dl_new_hash (s=0xd5d003f7 ) 
at dl-lookup.c:477  
477 dl-lookup.c: No such file or directory.
(gdb) bt
#0  0xb7fe8329 in dl_new_hash (s=0xd5d003f7 ) at dl-lookup.c:477
#1  _dl_lookup_symbol_x (undef_name=0xd5d003f7 , undef_map=undef_map@entry=0x89d33a0, ref=ref@entry=0xbfffd5e4, 
symbol_scope=symbol_scope@entry=0x89d3558, version=0x0, type_class=0, 
flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:717
#2  0xb7fe9fd1 in elf_machine_rel (sym=0xb0ae7738, skip_ifunc=0, 
reloc_addr_arg=0xab78e000, version=, map=0x89d33a0, 
reloc=)
at ../sysdeps/i386/dl-machine.h:339

  This happens even after I removed my entire address book, as describg in the 
email thread regarding:
  bug#682685: 2nd follow-up to Re: libglib-2.0: claws-mail segfault 
(https://groups.google.com/forum/?fromgroups#!topic/linux.debian.bugs.dist/fx_NUUHL2EI)

* What exactly did you do (or not do) that was effective (or ineffective)?

  Can work around this by waiting several minutes after claws-mail starts up 
before selecting any mail in the Inbox.
  Note that this problem only happens for mails in the Inbox; one can select an 
email in Trash, Drafts, Sent, etc. immediately
  after startup without any problem. Only emails in the Inbox cause the 
segmentation fault.

  Claws-mail should continue to run without crashing after selecting an email 
in Inbox right after startup, just
  as it does when selecting an email in the other mail folders just after 
startup.


  Full stack trace:
folder.c:2577:Total cache memory usage: 202999
folderview.c:2240:TIMING folderview_selected : 0s447ms
folderview.c:2118:newly selected 0x864b790, opened 0x864b790
folderview.c:2122:TIMING folderview_selected : 0s000ms
folder.c:4620:Folder jack wants sync
folder.c:4620:Folder jack wants sync
folder.c:4620:Folder jack wants sync
folder.c:4620:Folder jack wants sync
folder.c:4620:Folder jack wants sync
folder.c:4620:Folder jack wants sync
imap.c:1447:trying to fetch cached 
/home/jack/.claws-mail/imapcache/localhost/jack/INBOX/11902
imap.c:1456:message 11902 has been already fully cached.
message/rfc822 (offset:0 length:24802 encoding: 6)
multipart/mixed (offset:2844 length:21958 encoding: 6)
multipart/alternative (offset:2983 length:21771 encoding: 6)
text/plain (offset:3101 length:2629 encoding: 0)
text/html (offset:5848 length:18858 encoding: 0)
mimeview.c:854:text/html
fancy_viewer.c:856:fancy_viewer_create
[New Thread 0xad7ffb40 (LWP 31837)]
[New Thread 0xacefeb40 (LWP 31838)]
[New Thread 0xac4ffb40 (LWP 31839)]

Program received signal SIGSEGV, Segmentation fault.
0xb7fe8329 in dl_new_hash (s=0xd5d003f7 ) 
at dl-lookup.c:477
477 dl-lookup.c: No such file or directory.
(gdb) bt
#0  0xb7fe8329 in dl_new_hash (s=0xd5d003f7 ) at dl-lookup.c:477
#1  _dl_lookup_symbol_x (undef_name=0xd5d003f7 , undef_map=undef_map@entry=0x89d33a0, ref=ref@entry=0xbfffd5e4, 
symbol_scope=symbol_scope@entry=0x89d3558, version=0x0, type_class=0, 
flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:717
#2  0xb7fe9fd1 in elf_machine_rel (sym=0xb0ae7738, skip_ifunc=0, 
reloc_addr_arg=0xab78e000, version=, map=0x89d33a0, 
reloc=)
at ../sysdeps/i386/dl-machine.h:339
#3  elf_dynamic_do_Rel (skip_ifunc=0, lazy=, 
nrelative=, relsize=, reladdr=, 
map=0x89d33a0) at do-rel.h:137
#4  _dl_relocate_object (scope=0x89d3558, reloc_mode=reloc_mode@entry=0, 
consider_profiling=0, consider_profiling@entry=5) at dl-reloc.c:265
#5  0xb7ff1de7 in dl_open_worker (a=a@entry=0xbfffd7ec) at dl-open.c:420
#6  0xb7fedb2e in _dl_catch_error (objname=objname@entry=0xbfffd7e4, 
errstring=errstring@entry=0xbfffd7e8, mallocedp=mallocedp@entry=0xbfffd7e3, 
operate=operate@entry=0xb7ff1a00 , 
args=args@entry=0xbfffd7ec) at dl-error.c:177
#7  0xb7ff15d4 in _dl_open (file=0x89d2390 
"/usr/lib/libproxy/0.3.1/modules/pacrunner_mozjs.so", mode=-2147483646, 
caller_dlopen=caller_dlopen@entry=0xaed941ac 
, nsid=-2, argc=argc@entry=2, 
argv=argv@entry=0xb484, env=0x83f4690) at dl-open.c:656
#8  0xb6cc4cce in dlopen_doit (a=a@entry=0xbfffd9a0) at dlopen.c:66
#9  0xb7fedb2e in _dl_catch_error (ob