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

2024-04-27 Thread 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.

2023-09-12 Thread 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

2023-09-12 Thread 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

2023-07-15 Thread 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 

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

2023-03-17 Thread 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

2023-03-15 Thread 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

2023-03-14 Thread 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

2023-02-19 Thread 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

2023-02-19 Thread 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

2023-02-13 Thread 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

2023-02-05 Thread 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

2023-02-03 Thread 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

2023-01-27 Thread 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

2023-01-06 Thread 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)

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


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

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

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

decoder {
    plugin "mpg123"
    enabled "no"
}



thanks again,--jack

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

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

It has been closed by Florian Schlichting .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Florian Schlichting 
 by
replying to this email.


-- 
990160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
On Sun, Jul 04, 2021 at 12:02:13AM +, js jb wrote:
>  After posting the files to reproduce the problem on github, they posted a 
>work-around for this issue:
> In /etc/mpd.conf, disable the 'mad' decoder with the lines:decoder {
>    plugin "mad"
>    enabled "no"
> }This solved the problem.

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

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

Dear Maintainer,

==

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

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

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

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

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

==


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

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

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

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

2021-10-11 Thread 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

2020-02-04 Thread 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

2018-04-21 Thread 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

2018-04-09 Thread 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

2018-03-27 Thread js jb


Package: eog
Version: 3.28.0-2
Severity: important

Dear Maintainer,

=
After upgrading to eog 3.28.0-2 I saw it continues to fail when opening 24MP 
(6000x4000) JPG files,
although it still works on smaller 8MP files). This used to work as late as eog 
3.26 and there is no problemopening these files with ristretto or geeqie.
Below are some of the messages from /var/log/messages for eog and a backtrace 
of eog (withoug debug
symbols as eog-dbg 3.28 is not yet available on testing):



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


=> export GDK_SYNCHRONIZE=1
ME:=> gdb `which eog`
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/eog...(no debugging symbols found)...done.
(gdb) b gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) r A6K01000.JPG
Starting program: /usr/bin/eog A6K01000.JPG
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb3bdeb40 (LWP 16053)]
[New Thread 0xb31ffb40 (LWP 16054)]
[New Thread 0xb27ffb40 (LWP 16055)]
[New Thread 0xb1dffb40 (LWP 16056)]
[New Thread 0xace2eb40 (LWP 16057)]

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

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

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

2018-02-26 Thread 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

2018-02-11 Thread 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

2018-01-16 Thread 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

2018-01-16 Thread 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

2017-12-01 Thread 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

2017-10-25 Thread 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 <j...@debian.org>
 To: js <em2ja...@yahoo.com>; 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

2017-10-25 Thread js
-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/archive/debian/20110909T151822Z/ wheezy main 
contrib non-free
#deb-src http://snapshot.debian.org/archive/debian/20110909T151822Z/ wheezy 

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

2017-07-10 Thread 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 <apoi...@debian.org>
 To: JS <jsh...@yahoo.com>; 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

2017-07-07 Thread 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

2017-06-13 Thread 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 <a...@debian.org>
 To: js <jsh...@yahoo.com>; 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 <a...@debian.org>, 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

2017-05-15 Thread 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=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

2016-09-24 Thread 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.

2016-03-24 Thread 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

2015-12-23 Thread 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 <da...@kalnischkies.de>
 To: js <jsh...@yahoo.com>; 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

2015-08-29 Thread 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 lu...@debian.org (Bug#760075: fixed in torsocks 2.1.0-1)

2015-07-01 Thread 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 jsh...@yahoo.com wrote:

 From: JS jsh...@yahoo.com
 Subject: Re: Bug#760075 closed by Jérémy Bobbio lu...@debian.org 
 (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
 ow...@bugs.debian.org
 wrote:
 
  Subject: Bug#760075 closed
 by Jérémy Bobbio lu...@debian.org
 (Bug#760075: fixed in torsocks 2.1.0-1)
  To:
 js jsh...@yahoo.com
  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 lu...@debian.org.
  
  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 lu...@debian.org
  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 lu...@debian.org (Bug#760075: fixed in torsocks 2.1.0-1)

2015-07-01 Thread 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 ow...@bugs.debian.org wrote:

 Subject: Bug#760075 closed by Jérémy Bobbio lu...@debian.org (Bug#760075: 
fixed in torsocks 2.1.0-1)
 To: js jsh...@yahoo.com
 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 lu...@debian.org.
 
 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 lu...@debian.org
 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)

2015-06-27 Thread 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

2015-06-22 Thread 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 none
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 none 

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 none

2015-06-16 21:58:50 status installed libc-bin:i386 2.19-18


thanks,
 Jack Shaio


On Mon, 6/22/15, Magnus Holmgren holmg...@debian.org wrote:

 Subject: Re: Bug#789119: libnettle6 install leaves libnettle4, causing 
segfaults on many applications
 To: js jsh...@yahoo.com, 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

2015-06-17 Thread 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 none
2015-04-23 12:12:25 status installed libnettle4:i386 2.7.1-5
2015-06-14 18:26:02 install libnettle6:i386 none 3.1.1-3
2015-06-14 18:26:31 configure libnettle6:i386 3.1.1-3 none
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 none



= 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 

Bug#787620: many libnettle4 segmentation faults after installing libnettle6

2015-06-16 Thread 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 none 3.1.1-3
2015-06-14 18:26:31 configure libnettle6:i386 3.1.1-3 none
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 none

===


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

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

2015-05-15 Thread 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:

  Menu
NameInternet/Name
DirectoryInternet.directory/Directory ### entire Internet directory 
did not appear

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

Menu
 NameBrowsers/Name
 DirectoryBrowsers.directory/Directory

 Include
CategoryJack-Browsers/Category
 /Include
/Menu

Menu
 NameEmail/Name
 DirectoryEmail.directory/Directory
 Include
CategoryJack-Email/Category
 /Include
/Menu

Menu
 NameNetwork/Name
 DirectoryNetwork.directory/Directory
 Include
CategoryJack-Network/Category
 /Include
/Menu

   /Menu

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#782080: libmtp-runtime: missing Motorola Droid Turbo Device 0 (VID=22b8 and PID=2ea8) is UNKNOWN

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

2015-04-07 Thread 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_date.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#772471: closed by Michael Gilbert mgilb...@debian.org (Re: Bug#772471: chromium crash on startup)

2014-12-20 Thread 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 ow...@bugs.debian.org
To: js jsh...@yahoo.com
Cc: 
Sent: Friday, December 19, 2014 7:45 PM
Subject: Bug#772471 closed by Michael Gilbert mgilb...@debian.org (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 mgilb...@debian.org.

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 
mgilb...@debian.org 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=439795thanks=439795ts=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

2014-12-18 Thread 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=2start=0#=100q=colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modifiedgroupby=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 with error: FATAL:sandbox_bpf.cc(502)] Check failed: -1 == rv (-1 vs. 354)

2014-12-07 Thread 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=439795thanks=439795ts=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#772471: chromium crash on startup

2014-12-07 Thread 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=439795thanks=439795ts=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 mgilb...@debian.org
 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

2014-12-07 Thread 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=439795thanks=439795ts=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 mgilb...@debian.org
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#767659: evince 3.14.1-1 gets undefined symbol with libpoppler46:i386 earlier than 0.26.5-2

2014-11-01 Thread 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 none

-- 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

2014-10-20 Thread 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 dl_open_worker, 
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 
osgDB::DynamicLibrary::getLibraryHandle(std::string const)+128, 
nsid=optimized out, 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 dlopen_doit, args=0xac3588e0)
at dl-error.c:187
#6  0xb694a37c in _dlerror_run (operate=operate@entry=0xb6949c30 dlopen_doit, 
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::TexBuilderosg::Texture2D::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

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

2014-10-11 Thread 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 altha...@gmail.com
 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

2014-09-10 Thread 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 intrig...@debian.org
To: 684...@bugs.debian.org; 761...@bugs.debian.org
Cc: JS jsh...@yahoo.com; David Goulet dgou...@ev0ke.net
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

2014-09-03 Thread 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 dgou...@ev0ke.net
To: intrigeri intrig...@debian.org
Cc: JS jsh...@yahoo.com; 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=optimized out) 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#684580: SIGSEGV in torsocks 2.0.0-1

2014-09-03 Thread JS
David,

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

 
thanks,
--jack


- Original Message -
From: David Goulet dgou...@ev0ke.net
To: JS jsh...@yahoo.com
Cc: intrigeri intrig...@debian.org; 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 dgou...@ev0ke.net
 To: intrigeri intrig...@debian.org
 Cc: JS jsh...@yahoo.com; 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=optimized out) 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 torified for this shell.
 = gdb midori
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i586-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols

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

2014-08-31 Thread 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=optimized out) 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
 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#760075: torsocks: SIGSEGV with torsocks 2.0.0 on some browsers, failure to anonimize others

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

2014-08-30 Thread 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=optimized out) 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 none
2014-08-30 10:25:34 configure tor-geoipdb:all 0.2.4.23-1 none
2014-08-30 10:25:34 configure torsocks:i386 2.0.0-1 none
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

2014-07-20 Thread 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

2014-07-13 Thread 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/LinuxDebian 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/LinuxDebian 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_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 
--hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3'  
43cbbe73-0f2d-4649-a682-841b910498d2
else
  search

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

2014-06-11 Thread 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)

2014-05-27 Thread 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

2014-03-24 Thread 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 none
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 none
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 none        
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 none
2014-03-23 11:14:40 status installed texlive-omega:all 2013.20140314-1


 
thanks,
--jack



 From: Norbert Preining prein...@logic.at
To: js jsh...@yahoo.com; 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

2014-03-24 Thread 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 jsh...@yahoo.com
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 jsh...@yahoo.com
To: Norbert Preining prein...@logic.at; 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 none
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 none
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 none        
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 none
2014-03-23 11:14:40 status installed texlive-omega:all 2013.20140314-1


 
thanks,
--jack



 From: Norbert Preining prein...@logic.at
To: js jsh...@yahoo.com; 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

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

2014-03-24 Thread 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 jsh...@yahoo.com
To: Norbert Preining prein...@logic.at; 673...@bugs.debian.org 
673...@bugs.debian.org 
Cc: jsh...@yahoo.com 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 jsh...@yahoo.com
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 jsh...@yahoo.com
To: Norbert Preining prein...@logic.at; 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
 none
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 none
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 none        
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 none
2014-03-23 11:14:40 status installed texlive-omega:all 2013.20140314-1


 
thanks,
--jack



 From: Norbert Preining prein...@logic.at
To: js jsh...@yahoo.com; 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

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

2014-03-23 Thread 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#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

2014-03-23 Thread 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#673022: texlive-base: happened with upgrade to 2013.20140123-1 from 2013.20140314-1

2014-03-23 Thread JS
The zipped file /tmp/fmtutil.3YhQeNol mentioned below is attached.
 
thanks, 
--jack



 From: js jsh...@yahoo.com
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)

Kernel: Linux 3.2.0-4-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US, LC_CTYPE

Bug#737411: xdg-utils: xdg-screensaver needs to default PATH to standard dirs to avoid excess CPU usage

2014-02-02 Thread 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)

2014-01-27 Thread 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 cor...@debian.org
To: JS jsh...@yahoo.com 
Cc: 736...@bugs.debian.org 736...@bugs.debian.org; Debian Bug Tracking 
System sub...@bugs.debian.org 
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: parole: add media option to play DVD (instead of entering dvd:// in location)

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

2014-01-26 Thread 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 cor...@debian.org
To: js jsh...@yahoo.com; 736...@bugs.debian.org 
Cc: Debian Bug Tracking System sub...@bugs.debian.org 
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#732137: gnustep-gui-doc: missing .../Gui/ProgrammingManual/manual_toc.html referenced in GNUStep doc index.html

2013-12-14 Thread 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

2013-11-03 Thread 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 jsh...@yahoo.com
 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~)

2013-10-28 Thread 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

2013-10-27 Thread 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   none

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~)

2013-10-10 Thread 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 r...@debian.org (Re: Bug#725219: libreoffice: apt-get install libreoffice: wants to remove gnome)

2013-10-06 Thread 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 r...@debian.org
To: JS jsh...@yahoo.com; 725...@bugs.debian.org 
Sent: Sunday, October 6, 2013 10:12 AM
Subject: Re: Bug#725219: closed by Rene Engelhard r...@debian.org (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

2013-10-02 Thread 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   none
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   none
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  none
pn  libreoffice-help-4.1  none
pn  libreoffice-l10n-4.1  none
pn  libreoffice-officebeannone
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  

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

2013-09-10 Thread 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 vincentc1...@gmail.com
To: JS jsh...@yahoo.com 
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 jsh...@yahoo.com 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: closed by Andreas Beckmann a...@debian.org (Re: Bug#722258: glx-diversions fails libGL.so.1 - /etc/alternatives)

2013-09-10 Thread 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 ow...@bugs.debian.org
To: js jsh...@yahoo.com 
Sent: Tuesday, September 10, 2013 8:30 AM
Subject: Bug#722258 closed by Andreas Beckmann a...@debian.org (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 a...@debian.org.

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 
a...@debian.org 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.
    Unpacking glx-alternative-mesa (from 
.../glx

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

2013-09-09 Thread 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 

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

2013-09-09 Thread 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#720449: apt-utils 0.9.9.4 needs dependency on libapt-inst1.5 = 0.9.9.4

2013-08-22 Thread 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

2013-08-21 Thread 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

2013-07-13 Thread 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 otherwise always get Invalid HTTP request

2013-07-11 Thread 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#716695: googleearth-package: needs to remove libcurl.so.4 from googleearth

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

2013-07-03 Thread 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/ME/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 mo...@debian.org
 To: js jsh...@yahoo.com; 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 Address 0xd5d003f7 out of 
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 Address 0xd5d003f7 out of bounds) at dl-lookup.c:477
     #1  _dl_lookup_symbol_x (undef_name=0xd5d003f7 Address 0xd5d003f7 out of 
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=optimized out, map=0x89d33a0, 
reloc=optimized
 out)
         at ../sysdeps/i386/dl-machine.h:339
     #3  elf_dynamic_do_Rel (skip_ifunc=0, lazy=optimized out, 
nrelative=optimized out, relsize=optimized out, reladdr=optimized out, 
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 dl_open_worker, 
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 
px_module_manager_load+348, 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=0x83fbbf8

Bug#702757: googleearth 7 needed to search

2013-06-29 Thread 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

2013-06-19 Thread 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

2013-06-10 Thread 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 Address 0xd5d003f7 out of 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 Address 0xd5d003f7 out of 
bounds) at dl-lookup.c:477
#1  _dl_lookup_symbol_x (undef_name=0xd5d003f7 Address 0xd5d003f7 out of 
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=optimized out, map=0x89d33a0, 
reloc=optimized out)
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 Address 0xd5d003f7 out of 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 Address 0xd5d003f7 out of 
bounds) at dl-lookup.c:477
#1  _dl_lookup_symbol_x (undef_name=0xd5d003f7 Address 0xd5d003f7 out of 
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=optimized out, map=0x89d33a0, 
reloc=optimized out)
at ../sysdeps/i386/dl-machine.h:339
#3  elf_dynamic_do_Rel (skip_ifunc=0, lazy=optimized out, 
nrelative=optimized out, relsize=optimized out, reladdr=optimized out, 
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 dl_open_worker, 
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, 
  

Bug#710508: linux-image-3.2.0-4-amd64: random Wheezy freeze

2013-05-31 Thread JS Ubei
Package: linux-image-3.2.0-4-amd64

Version: 3.2.41-2

Severity:important

The bug #703715 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703715) is 
still present in the last (3.2.41-2) kernel version, my system freeze very 
often.
Thanks to take it in account.


--
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

2013-05-29 Thread JS Ubei
Same for me, 

I am still able to reproduce this bug with my up to date wheezy.

My computer freeze two time this morning when I was scrolling a libreoffice 
writer doc.

And no, I can't switch to a console to kill the X session, whole computer is 
frozen.




 De : Davide Prina davide.pr...@gmail.com
À : 703...@bugs.debian.org 
Cc : jsu...@yahoo.fr; samuelwol...@googlemail.com; dan...@pocock.com.au; 
piruthivi...@gmail.com 
Envoyé le : Vendredi 17 mai 2013 20h05
Objet : Re: linux-image-3.2.0-4-amd64: random Wheezy freeze
 

I think that this bug is not present with the latest Linux version 
entered in Wheezy two day ago.
I haven't no freeze in two days.

I have CC to all people so all you can confirm if the bug is not present 
in the last Wheezy Linux version.

@piruthiviraj natarajan

probably you have another bug. I don't know (have understand) what is 
the package responsible for that (gnome-shell?)
I think the bug you have can be resolved with the followings steps 
without killing the X session:

Ctrl-Alt-F1
- login as your user (not root)
$ killall -9 gnome-shell
$ exit
Alt-F7

You have all your windows working again and you don't lose nothing.

Ciao
Davide

-- 
Dizionari: http://linguistico.sourceforge.net/wiki
Database: http://www.postgresql.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Bug#704914: glx-diversions: More system information

2013-04-07 Thread JS
I read this bug with interest although I've had no problem using nvidia drivers 
304.64-4 with gnome 3.4.


Possibly related, note below that for the libGL.so library mentioned, libGL.so 
points to the mesa diversion while libGL.so.1 points to the nvidia version.

Isn't this an anomaly? [ie, normally wouldn't libGL.so - libGL.soversion in 
the same directory?]


= for i in  /usr/lib/i386-linux-gnu/libGL.so*; do printf %s\t%s\n $i 
`readlink -f $i`; done
/usr/lib/i386-linux-gnu/libGL.so
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2                     
should libGL.so - libGL.so.1 instead?
/usr/lib/i386-linux-gnu/libGL.so.1  
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.304.64


Relevant package versions: 

ii  glx-alternative-mesa0.2.2   
    
ii  glx-alternative-nvidia  0.2.2   
    
ii  glx-diversions  0.2.2   
i386  
ii  nvidia-kernel-dkms  304.64-4
  
ii gnome 1:3.4+6
ii  linux-image-3.2.0-4-686-pae 3.2.35-2  

thanks,
--jack


 From: pkg-nvidia-devel-requ...@lists.alioth.debian.org 
pkg-nvidia-devel-requ...@lists.alioth.debian.org
To: pkg-nvidia-de...@lists.alioth.debian.org 
Sent: Sunday, April 7, 2013 12:39 PM
Subject: pkg-nvidia-devel Digest, Vol 69, Issue 12
 
Send pkg-nvidia-devel mailing list submissions to
    pkg-nvidia-de...@lists.alioth.debian.org



Message: 5
Date: Sun, 07 Apr 2013 12:30:09 -0400
From: Christian Weeks c...@weeksfamily.ca
To: Debian Bug Tracking System 704...@bugs.debian.org
Subject: Bug#704914: glx-diversions: More system information
Message-ID:
    20130407163009.16551.67955.report...@smartie.weeksfamily.ca
Content-Type: text/plain; charset=us-ascii

Package: glx-diversions
Version: 0.2.90
Followup-For: Bug #704914

Data from reportbug

-- Package-specific info:
Diversions:
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib32/libGL.so to /usr/lib32/nvidia/diversions/libGL.so by 
libgl1-nvidia-alternatives-ia32
diversion of /usr/lib32/libGL.so.1 to /usr/lib32/nvidia/diversions/libGL.so.1 
by libgl1-nvidia-alternatives-ia32
diversion of /usr/lib32/libGL.so.1.2 to 
/usr/lib32/nvidia/diversions/libGL.so.1.2 by libgl1-nvidia-alternatives-ia32

/usr/lib/mesa-diverted:
total 64
drwxr-xr-x   4 root root  4096 Oct  1  2012 .
drwxr-xr-x 236 root root 49152 Apr  7 11:36 ..
drwxr-xr-x   2 root root  4096 Mar 18 12:30 i386-linux-gnu
drwxr-xr-x   2 root root  4096 Mar 18 12:31 x86_64-linux-gnu

/usr/lib/mesa-diverted/i386-linux-gnu/:
total 8
drwxr-xr-x 2 root root 4096 Mar 18 12:30 .
drwxr-xr-x 4 root root 4096 Oct  1  2012 ..
lrwxrwxrwx 1 root root   14 Dec 29 23:03 libGL.so.1 - libGL.so.1.2.0

/usr/lib/mesa-diverted/x86_64-linux-gnu/:
total 8
drwxr-xr-x 2 root root 4096 Mar 18 12:31 .
drwxr-xr-x 4 root root 4096 Oct  1  2012 ..
lrwxrwxrwx 1 root root   14 Dec 29 22:24 libGL.so - libGL.so.1.6.0
lrwxrwxrwx 1 root root   14 Dec 29 22:24 libGL.so.1 - libGL.so.1.2.0

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

lrwxrwxrwx 1 root root 15 Apr  7 12:23 /etc/alternatives/glx - 

Bug#703715: linux-image-3.2.0-4-amd64: random Wheezy freeze

2013-04-05 Thread JS Ubei
Dear all,
Just another information about the bug.

I've installed the sid kernel:

 apt-cache policy linux-image-3.2.0-4-amd64
linux-image-3.2.0-4-amd64:
  Installé : 3.2.41-2
  Candidat : 3.2.41-2
 Table de version :
 *** 3.2.41-2 0
 90 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages
    100 /var/lib/dpkg/status
 3.2.39-2 0
    990 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages

But unfortunatly this does not totaly resolved the bug. It's seem to be more 
stable (less freeze) but not totaly: my laptop just freeze two times in the 
last two hours ...

Best regards,

Bug#703715: linux-image-3.2.0-4-amd64: random Wheezy freeze

2013-03-26 Thread JS Ubei
Dear all,

I have exactly the same problem.

Same intel GPU, same usage of a libreOffice writer document which totaly freeze 
my system when I scroll, and same solution : I use the previous kernel 
linux-image-3.2.0-3.

Thank you.

Norbert

Bug#699412: intel-ucode for Xeon W3690 missing after upgrade from 3.1 to 3.2 linux-image

2013-02-21 Thread JS
699...@bugs.debian.org,

 
My computer has an Intel Xeon W3690 (details from dmidecode at bottom) and has 
worked without problem
using linux-image-3.1.0-1-686-pae 3.1.8-2.

I upgraded to linux-image-3.2.0-4-686-pae:i386 3.2.35-2 and get a similar 
message as reported in this bug:

microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x13
platform microcode: firmware: agent aborted loading intel-ucode/06-2c-02 
(not found?)

However the computer still boots and has worked normally. This message did not 
appear with the earlier 3.1 kernel on
the same PC and there were no hardware changes, so it would seem related to the 
linux-3.2 image. The computer boots
without this message when I use the older linux 3.1 kernel.

The message does not appear on an older PC running the same linux-3.2 image but 
with an Intel Core 2 6300 (that one loads a different ucode
for which there is a file in /lib/firmware/intel-ucode).

I'm not clear on two points:
1. is this a problem since the computer boots and works normally despite the 
message? [In other words, is an earlier version
    of ucode being used?]

2. is there any configuration or package install/remove I could do to avoid 
this issue when booting linux-3.2t?

thanks,
--jack


From dmidecode:

Handle 0x0004, DMI type 4, 40 bytes
Processor Information
Socket Designation: LGA1366
Type: Central Processor
Family: Xeon
Manufacturer: Intel 
ID: C2 06 02 00 FF FB EB BF
Signature: Type 0, Family 6, Model 44, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Xeon(R) CPU W3690 @ 3.47GHz 
Voltage: 1.2 V
External Clock: 133 MHz
Max Speed: 3466 MHz
Current Speed: 3466 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: 0x0007
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 6
Core Enabled: 6
Thread Count: 6
Characteristics:
64-bit capable

Bug#683930: eclipse: 3.8.0~rc4-1 exits with log error: Unable to acquire application

2012-08-11 Thread JS
Jakub,


I tried your suggestion and got exactly the same error, details below.

This isn't surprising since the eclipse 3.8 blob from eclipse.org runs 
perfectly on my system,

so any packages needed for eclipse 3.8 had to be already present.


Here are the details:

+++---
ii libfelix-gogo-command-java 0.12.0-1 Apache Felix Gogo Command bundle
un libfelix-gogo-command-java-doc none (no description available)
ii libfelix-gogo-runtime-java 0.10.0-1 Apache Felix Gogo Runtime bundle
un libfelix-gogo-runtime-java-doc none (no description available)
ii libfelix-gogo-shell-java 0.10.0-1 Apache Felix Gogo Shell bundle
un libfelix-gogo-shell-java-doc none (no description available)
ii libservlet3.0-java 7.0.28-2 Servlet 3.0 and JSP 2.2 Java API classes
ii libtomcat7-java 7.0.28-2 Servlet and JSP engine -- core libraries
ii eclipse 3.8.0~rc4-1 Extensible Tool Platform and Java IDE

 
jack@berkeley:~ = eclipse -console -consoleLog -noExit
!SESSION 2012-08-11 19:34:09.365 ---
eclipse.buildId=unknown
java.version=1.7.0_05
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Command-line arguments:  -os linux -ws gtk -arch x86 -console -consoleLog

!ENTRY org.eclipse.osgi 4 0 2012-08-11 19:34:09.633
!MESSAGE Could not find bundle: org.eclipse.equinox.console
!STACK 0
org.osgi.framework.BundleException: Could not find bundle: 
org.eclipse.equinox.console
at 
org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)
at 
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)

!ENTRY org.eclipse.osgi 4 0 2012-08-11 19:34:09.639
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Unable to acquire application service. Ensure 
that the org.eclipse.core.runtime bundle is resolved and started (see 
config.ini).
at 
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)


thanks,
--jack




 From: Jakub Adam jakub.a...@ktknet.cz
To: JS jsh...@yahoo.com 
Cc: 683...@bugs.debian.org 683...@bugs.debian.org 
Sent: Saturday, August 11, 2012 8:06 AM
Subject: Re: eclipse: 3.8.0~rc4-1 exits with log error: Unable to acquire 
application
 
Hi,

On 11.8.2012 05:18, JS wrote:
 I retried your suggestion but never got the console to look for the output 
 you suggested. Below is all I saw
 (also tried adding the -clean option, with the same result).
 
 jack@berkeley:~ = eclipse -console -consoleLog -noExit
 !SESSION 2012-08-10 23:05:56.732 
 ---
 eclipse.buildId=unknown
 java.version=1.7.0_05
 java.vendor=Oracle Corporation
 BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
 Command-line arguments: -os linux -ws gtk -arch x86 -console -consoleLog
 
 !ENTRY org.eclipse.osgi 4 0 2012-08-10 23:05:56.964
 !MESSAGE Could not find bundle: org.eclipse.equinox.console
 !STACK 0
 org.osgi.framework.BundleException: Could not find bundle: 
 org.eclipse.equinox.console
 at 
 org.eclipse.osgi.framework.internal.core.ConsoleManager.checkForConsoleBundle(ConsoleManager.java:211)
 at 
 org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)
 at 
 org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584

  1   2   >