Bug#900067: Toolbar icons fail to appear in jupyter notebook.

[Thomas Vaughan]

Package: jupyter-notebook
Version: 5.4.1-1

Attached is a screen-captured image of the problem that I see.

Also attached is the output from the 'jupyter notebook' command to the terminal.

I expected to see icons on the toolbar under the menu, but instead I
saw only a rectangle where each icon should be. The mouse-hover text
is the only way to see what each button would do.

Output of 'uname -a':
Linux tevaugha-lt 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29)
x86_64 GNU/Linux

Output of 'ls -l /lib/*/libc.so.6':
lrwxrwxrwx 1 root root 12 Mar 29 13:47 /lib/x86_64-linux-gnu/libc.so.6
-> libc-2.27.so

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

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jupyter-notebook depends on:
ii  jupyter-core  4.4.0-2
ii  python3   3.6.5-3
ii  python3-notebook  5.4.1-1

jupyter-notebook recommends no packages.

jupyter-notebook suggests no packages.

-- no debconf information

-- 
Thomas E. Vaughan
 $ jupyter notebook
[I 09:26:24.553 NotebookApp] Serving notebooks from local directory: /home/tevaugha/Desktop/src/pstan/gyro-cal
[I 09:26:24.553 NotebookApp] 0 active kernels
[I 09:26:24.553 NotebookApp] The Jupyter Notebook is running at:
[I 09:26:24.553 NotebookApp] http://localhost:/?token=5c7709b49290d76aec54395b9176fab5f473139d02b249e8
[I 09:26:24.553 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 09:26:24.554 NotebookApp]

Copy/paste this URL into your browser when you connect for the first time, to login with a token:
http://localhost:/?token=5c7709b49290d76aec54395b9176fab5f473139d02b249e8
[I 09:26:28.449 NotebookApp] Accepting one-time-token-authenticated connection from ::1
[E 09:26:28.631 NotebookApp] Uncaught exception GET /api/config/tree?_=1527261988578 (::1)
HTTPServerRequest(protocol='http', host='localhost:', method='GET', uri='/api/config/tree?_=1527261988578', version='HTTP/1.1', remote_ip='::1')
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/tornado/web.py", line 1541, in _execute
result = method(*self.path_args, **self.path_kwargs)
  File "/usr/lib/python3/dist-packages/tornado/web.py", line 2949, in wrapper
return method(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/notebook/services/config/handlers.py", line 19, in get
self.finish(json.dumps(self.config_manager.get(section_name)))
  File "/usr/lib/python3/dist-packages/notebook/services/config/manager.py", line 25, in get
recursive_update(config, cm.get(section_name))
  File "/usr/lib/python3/dist-packages/notebook/config_manager.py", line 85, in get
recursive_update(data, json.load(f))
  File "/usr/lib/python3.6/json/__init__.py", line 299, in load
parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
[W 09:26:28.632 NotebookApp] Unhandled error
[E 09:26:28.633 NotebookApp] {
  "Host": "localhost:",
  "Connection": "keep-alive",
  "Accept": "application/json, text/javascript, */*; q=0.01",
  "X-Requested-With": "XMLHttpRequest",
  "X-Xsrftoken": "2|abb78dd7|f7bd4cd812d0051301e88455e708657f|1527075350",
  "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/66.0.3359.181 Safari/537.36",
  "Referer": "http://localhost:/tree;,
  "Accept-Encoding": "gzip, deflate, br",
  "Accept-Language": "en-US,en;q=0.9",
  "Cookie": "_xsrf=2|abb78dd7|f7bd4cd812d0051301e88455e708657f|1527075350; username-localhost-=\"2|1:0|10:1527261988|23:username-localhost-|44:YWRkZGIxMTk5MmExNGNiZDkxNmM3ZTA4OTQ5Yjc4M2Q=|53982762aaf7ce458e5fa1a8930e73c618e298a50480d44ef526410e84faf698\""
}
[E 09:26:28.633 NotebookApp] 500 GET /api/config/tree?_=1527261988578 (::1) 3.07ms referer=http://localhost:/tree
[E 09:26:28.635 NotebookApp] Uncaught exception GET /api/config/common?_=1527261988579 (::1)
HTTPServerRequest(protocol='http', host='localhost:', method='GET', uri='/api/config/common?_=1527261988579', version='HTTP/1.1', remote_ip='::1')
Traceback (most recent call last):
  File 

Bug#887122: gnome-user-share

[Thomas Vaughan]

Debugging the obamenu python script, I found that it freaks out when
it tries to read 'gnome-user-share.desktop'.  When I uninstalled the
'gnome-user-share' package, the problem went away.

-- 
Thomas E. Vaughan

Bug#887593: More apparmor="ALLOWED" messages in syslog.

[Thomas Vaughan]

I see that this bug is closed, but I see something similar in my
system log.  I am running Debian unstable updated as of yesterday.  It
seems that libreoffice is trying to make use of OpenCL, and I have a
couple of OpenCL ICDs installed.

After opening a PDF file in LibreOffice Draw, I saw the following from logcheck:

Feb 15 17:41:31 foo-machine kernel: [85508.697711] kauditd_printk_skb:
8 callbacks suppressed
Feb 15 17:41:31 foo-machine kernel: [85508.697712] audit: type=1400
audit(1518741691.452:20): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice" name="/etc/OpenCL/vendors/pocl.icd"
pid=11676 comm="soffice.bin" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
Feb 15 17:41:31 foo-machine kernel: [85509.116067] audit: type=1400
audit(1518741691.868:21): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice"
name="/sys/devices/system/node/node0/meminfo" pid=11676
comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000
ouid=0
Feb 15 17:41:32 foo-machine kernel: [85509.881791] audit: type=1400
audit(1518741692.636:22): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice" name="/etc/OpenCL/vendors/mesa.icd"
pid=11676 comm="soffice.bin" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
Feb 15 17:41:33 foo-machine kernel: [85510.820260] audit: type=1400
audit(1518741693.572:23): apparmor="ALLOWED" operation="file_mmap"
profile="libreoffice-soffice"
name="/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_nouveau.so"
pid=11676 comm="soffice.bin" requested_mask="m" denied_mask="m"
fsuid=1000 ouid=0
Feb 15 17:41:33 foo-machine kernel: [85510.877083] audit: type=1400
audit(1518741693.628:24): apparmor="ALLOWED" operation="file_mmap"
profile="libreoffice-soffice"
name="/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_nouveau.so"
pid=11676 comm="soffice.bin" requested_mask="m" denied_mask="m"
fsuid=1000 ouid=0
Feb 15 17:41:33 foo-machine kernel: [85510.883425] audit: type=1400
audit(1518741693.636:25): apparmor="ALLOWED" operation="file_mmap"
profile="libreoffice-soffice"
name="/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_swrast.so" pid=11676
comm="soffice.bin" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0
Feb 15 17:41:33 foo-machine kernel: [85510.975466] audit: type=1400
audit(1518741693.728:26): apparmor="ALLOWED" operation="mknod"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/mesa_shader_cache/index" pid=11676
comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000
Feb 15 17:41:33 foo-machine kernel: [85510.975479] audit: type=1400
audit(1518741693.728:27): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/mesa_shader_cache/index" pid=11676
comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000
ouid=1000
Feb 15 17:41:33 foo-machine kernel: [85510.975481] audit: type=1400
audit(1518741693.728:28): apparmor="ALLOWED" operation="truncate"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/mesa_shader_cache/index" pid=11676
comm="soffice.bin" requested_mask="w" denied_mask="w" fsuid=1000
ouid=1000
Feb 15 17:41:33 foo-machine kernel: [85511.100060] audit: type=1400
audit(1518741693.852:29): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice"
name="/etc/OpenCL/vendors/intel-beignet-x86_64-linux-gnu.icd"
pid=11676 comm="soffice.bin" requested_mask="r" denied_mask="r"
fsuid=1000 ouid=0
Feb 15 17:41:36 foo-machine kernel: [85513.938456] kauditd_printk_skb:
321 callbacks suppressed
Feb 15 17:41:36 foo-machine kernel: [85513.938457] audit: type=1400
audit(1518741696.692:351): apparmor="ALLOWED" operation="mknod"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/pocl/kcache/tempfile_d4JT7R.cl" pid=11676
comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000
Feb 15 17:41:36 foo-machine kernel: [85513.938476] audit: type=1400
audit(1518741696.692:352): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/pocl/kcache/tempfile_d4JT7R.cl" pid=11676
comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000
ouid=1000
Feb 15 17:41:36 foo-machine kernel: [85513.938502] audit: type=1400
audit(1518741696.692:353): apparmor="ALLOWED" operation="unlink"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/pocl/kcache/tempfile_d4JT7R.cl" pid=11676
comm="soffice.bin" requested_mask="d" denied_mask="d" fsuid=1000
ouid=1000
Feb 15 17:41:36 foo-machine kernel: [85513.938522] audit: type=1400
audit(1518741696.692:354): apparmor="ALLOWED" operation="mknod"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/pocl/kcache/tempfile_d4JT7R.cl.tmp"
pid=11676 comm="soffice.bin" requested_mask="c" denied_mask="c"
fsuid=1000 ouid=1000
Feb 15 17:41:36 foo-machine kernel: [85513.938531] audit: type=1400
audit(1518741696.692:355): apparmor="ALLOWED" operation="open"
profile="libreoffice-soffice"
name="/home/tevaugha/.cache/pocl/kcache/tempfile_d4JT7R.cl.tmp"
pid=11676 comm="soffice.bin" requested_mask="wrc" 

Bug#887122: I see this same problem on my up-to-date Debian sid system.

[Thomas Vaughan]

I see this same problem on my up-to-date Debian sid system.

-- 
Thomas E. Vaughan

Bug#883989: libreoffice-draw does not allow editing glue points

[Thomas Vaughan]

That's great news! It's interesting to me that this bug would seem to go so
long unreported, especially since it affects both MS Windows and Linux.

Maybe editing glue points is not commonly done (though I find such editing
essential to almost any drawing that I do).

Or maybe folks have been lazy like me and not reporting bugs as they
should, while sitting on an old version of Libreoffice and hoping for a fix
some day.

Anyway, it's good to know that a fix is on the way!

On Fri, Dec 15, 2017 at 2:41 AM, Rene Engelhard <r...@debian.org> wrote:

> found 883989 1:5.4.0~beta2-1
> tag 883989 upstream
> tag 883989 fixed-upstream
> forwarded 883989 https://bugs.documentfoundation.org/show_
> bug.cgi?id=113594
> thanks
>
> Hi,
>
> On Sat, Dec 09, 2017 at 10:38:59PM -0700, Thomas Vaughan wrote:
> > For the last few months, I have been unable to add visible glue points
> or to
> > edit existing glue points in an old drawing.  This problem has persisted
> since
> > I upgraded from stable to unstable.
>
> Sounds like https://bugs.documentfoundation.org/show_bug.cgi?id=113594
> which just got a commit backported into the libreoffice-6-0 branch so
> it is (probably) fixed in upcoming 6.0.0 rc1.
>
> Regards,
>
> Rene
>



-- 
Thomas E. Vaughan

Bug#883989: libreoffice-draw does not allow editing glue points

[Thomas Vaughan]

Package: libreoffice-draw
Version: 1:6.0.0~beta1-2
Severity: normal

Dear Maintainer,

For the last few months, I have been unable to add visible glue points or to
edit existing glue points in an old drawing.  This problem has persisted since
I upgraded from stable to unstable.

I recently tried the beta of libreoffice-6 in experimental, but it shows the
same behavior.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libreoffice-draw depends on:
ii  libavahi-client3 0.7-3
ii  libavahi-common3 0.7-3
ii  libc62.25-3
ii  libcdr-0.1-1 0.1.4-1
ii  libdbus-1-3  1.12.2-1
ii  libdbus-glib-1-2 0.108-3
ii  libfreehand-0.1-10.1.2-2
ii  libgcc1  1:7.2.0-17
ii  libglib2.0-0 2.54.2-1
ii  libicu57 57.1-8
ii  liblcms2-2   2.8-4
ii  libmspub-0.1-1   0.1.2-4+b1
ii  libmwaw-0.3-30.3.13-1
ii  libodfgen-0.1-1  0.1.6-2
ii  libpagemaker-0.0-0   0.0.3-2
ii  libpng16-16  1.6.34-1
ii  libqxp-0.0-0 0.0.0-1
ii  libreoffice-core 1:6.0.0~beta1-2
ii  librevenge-0.0-0 0.0.4-6
ii  libstaroffice-0.0-0  0.0.5-1
ii  libstdc++6   7.2.0-17
ii  libvisio-0.1-1   0.1.6-1
ii  libwpd-0.10-10   0.10.2-2
ii  libwpg-0.3-3 0.3.1-3
ii  libxml2  2.9.4+dfsg1-5.1
ii  libzmf-0.0-0 0.0.2-1
ii  uno-libs35.4.3-4+b1
ii  ure  5.4.3-4+b1
ii  zlib1g   1:1.2.8.dfsg-5

libreoffice-draw recommends no packages.

libreoffice-draw suggests no packages.

Versions of packages libreoffice-core depends on:
ii  fontconfig2.12.6-0.1
ii  fonts-opensymbol  2:102.10+LibO5.4.3-4
ii  libboost-date-time1.62.0  1.62.0+dfsg-4+b2
ii  libboost-locale1.62.0 1.62.0+dfsg-4+b2
ii  libc6 2.25-3
ii  libcairo2 1.15.8-2
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.6-2
ii  libcurl3-gnutls   7.57.0-1
ii  libdbus-1-3   1.12.2-1
ii  libdbus-glib-1-2  0.108-3
ii  libdconf1 0.26.1-1
ii  libeot0   0.01-4+b1
ii  libepoxy0 1.4.3-1
ii  libexpat1 2.2.3-2
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-0.1
ii  libgcc1   1:7.2.0-17
ii  libglib2.0-0  2.54.2-1
ii  libgpgmepp6   1.9.0-8
ii  libgraphite2-31.3.10-6
ii  libharfbuzz-icu0  1.7.2-1
ii  libharfbuzz0b 1.7.2-1
ii  libhunspell-1.6-0 1.6.2-1
ii  libhyphen02.8.8-5
ii  libice6   2:1.0.9-2
ii  libicu57  57.1-8
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.8-4
ii  libldap-2.4-2 2.4.45+dfsg-1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-2
ii  libnspr4  2:4.16-1+b1
ii  libnss3   2:3.34-1
ii  libodfgen-0.1-1   0.1.6-2
ii  liborcus-0.13-0   0.13.1-3
ii  libpng16-16   1.6.34-1
ii  libpoppler68  0.57.0-2
ii  librdf0   1.0.17-1.1
ii  libreoffice-common1:6.0.0~beta1-2
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.2-1+b3
ii  libstdc++67.2.0-17
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3
ii  libxml2   2.9.4+dfsg1-5.1
ii  libxmlsec11.2.25-1
ii  libxmlsec1-nss1.2.25-1
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.29-5
ii  uno-libs3 5.4.3-4+b1
ii  ure   5.4.3-4+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.24+nmu5

-- no debconf information

Bug#860119: gtk-window-decorator fails to run

[Thomas Vaughan]

Well, mine is not a custom build of compiz, but the stock compiz in Debian
testing.

Yet I see the problem and Have worked around it by modifying the schema in
glib.

Are you a Horta, or is your silicon nature that of an electronic kind?

On Thu, Apr 20, 2017 at 02:07 Ksamak <ksa...@hypra.fr> wrote:

> On Tue, Apr 11, 2017 at 11:02:58AM -0600, Thomas Vaughan wrote:
> >I don't know the the problem reported at your link is exactly the same
> >problem, but it looks related.
> >
> >In any event, my small patch to
> >/usr/share/glib-2.0/schemas/org.gnome.metacity.gschema.xml does allow
> >gtk-window-decorator to run.
> >
> >Might it be possible to build an updated compiz suite for the stretch
> >backports repository?
>
> Correct me if i'm wrong, but i know this patch, cause i've done it
> myself, but it only happens in local and custom builds, right?
> the error is something like:
> "no 'theme' value in org.gnome.metacity"
> --
> Ksamak
> silicon based life form
>
-- 
Thomas E. Vaughan

Bug#860119: gtk-window-decorator fails to run

[Thomas Vaughan]

I don't know the the problem reported at your link is exactly the same
problem, but it looks related.

In any event, my small patch to
/usr/share/glib-2.0/schemas/org.gnome.metacity.gschema.xml does allow
gtk-window-decorator to run.

Might it be possible to build an updated compiz suite for the stretch
backports repository?

On Tue, Apr 11, 2017 at 10:42 AM, Alex ARNAUD <alexarn...@hypra.fr> wrote:

> Hello Thomas,
> Thank you for using Compiz and pointing us bug.
>
> Le 11/04/2017 à 18:17, Thomas Vaughan a écrit :
>
>> Package: compiz-gnome
>> Version: 1:0.9.13.0+16.10.20160818.2-5
>>
>> ​When trying to run gtk-window-decorator, I saw this:
>>
>
> The version of Compiz in Debian is an old one. Due to the Debian freeze
> delay we have decided to not upload the latest Compiz release to avoid
> breakage.
>
> Is the same issue as described here ? https://bugs.launchpad.net/com
> piz/+bug/1629749
>
> If yes, It could be a good idea to upload a new Compiz release on the
> experimental repository that I expect will fix this compatibility issue.
>
> Best regards.
> --
> Alex ARNAUD
> Visual-Impairment Project Manager
> Hypra - "Humanizing technology"
>



-- 
Thomas E. Vaughan

Bug#860119: gtk-window-decorator fails to run

[Thomas Vaughan]

Package: compiz-gnome
Version: 1:0.9.13.0+16.10.20160818.2-5

​When trying to run gtk-window-decorator, I saw this:

​(gtk-window-decorator:28962): GLib-GIO-ERROR **: Settings schema
'org.gnome.metacity' does not contain a key named 'theme'
Trace/breakpoint trap

I have both gnome-flashback installed and compiz installed.


WORK-AROUND

My current work-around is based on what I found here:
https://mail.gnome.org/archives/gnome-flashback-list/2015-December/msg00038.html

First, I modified
/usr/share/glib-2.0/schemas/org.gnome.metacity.gschema.xml as follows:

--- org.gnome.metacity.gschema.xml-debian2017-04-11 09:51:44.530417746
-0600
+++ org.gnome.metacity.gschema.xml2017-04-11 09:53:57.998601455 -0600
@@ -66,6 +66,15 @@
   
 

+
+   'Adwaita'
+   Current theme
+   
+  The theme determines the appearance of window borders, titlebar,
and
+  so forth.
+   
+
+
 
 

​Then, I ran 'sudo glib-compile-schemas /usr/share/glib-2.0/schemas'.​

That work-around allows for windows to be decorated, but it is probably
just an ugly hack that does not fix the problem correctly. It looks to my
naive eye as though compiz-gnome should be updated to know about new newer
schema stuff. I think that I might just patched back in a bit of
otherwise-obsolete schema stuff that has been removed upstream.

-- 
Thomas E. Vaughan

Bug#853100: linux-image-4.9.0-1-amd64: Blocked tasks and no X on Latitude E6530

[Thomas Vaughan]

Attached is a copy of /var/log/messages from boot up until just after the
time of the first occurrence of the report of a blockage more than 120
seconds.

I notice that there is a new kernel package in unstable today. I'll check
that out, too.


On Sat, Feb 18, 2017 at 1:38 PM, Ben Hutchings <b...@decadent.org.uk> wrote:

> On Thu, 2017-02-16 at 20:17 -0700, Thomas Vaughan wrote:
> > I have attached the output both for linux-3.16 (which seems to have no
> > problem) and for linux-4.9.
>
> OK, so you have the VirtalBox and Broadcom wl modules loaded.  I doubt
> that they are involved in this bug.
>
> Can you look through /var/log/messages and extract the messages around
> the same time as "INFO: task worker/1:1:68 blocked for more than 120
> seconds"?
>
> Ben.
>
> --
> Ben Hutchings
> Knowledge is power.  France is bacon.
>



-- 
Thomas E. Vaughan


messages-2017-Feb-19
Description: Binary data

Bug#853100: linux-image-4.9.0-1-amd64: Blocked tasks and no X on Latitude E6530

[Thomas Vaughan]

I suppose that the vbox* modules built by way of dkms count as out-of-tree.

On Thu, Feb 16, 2017 at 8:17 PM, Thomas Vaughan <tevaug...@gmail.com> wrote:

> I have attached the output both for linux-3.16 (which seems to have no
> problem) and for linux-4.9.
>
> On Thu, Feb 16, 2017 at 8:01 PM, Ben Hutchings <b...@decadent.org.uk>
> wrote:
>
>> On Fri, 2017-02-17 at 02:26 +, Thomas Vaughan wrote:
>> > No, I'm using only the free-software drivers.
>> >
>> > What's a bit odd is that both mode-setting (for Intel gpu) and nouveau
>> (for
>> > nvidia gpu) are used when I am docked (because of Optimus feature of
>> > laptop).
>> >
>> > But problem shows when either docked or not.
>> >
>> > Problem appeared with Linux-4.9. There was no problem with Linux-4.8;
>> > bummer when Linux-4.8 disappeared from the Debian repositories.
>> >
>> > What counts as out-of-tree?
>>
>> Anything that's not part of the linux-image-* packages.
>>
>> Can you just send the output of:
>>
>> cut -d' ' -f1,7 /proc/modules | sed 's/ //'
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Any sufficiently advanced bug is indistinguishable from a feature.
>>
>
>
>
> --
> Thomas E. Vaughan
>



-- 
Thomas E. Vaughan

Bug#853100: linux-image-4.9.0-1-amd64: Blocked tasks and no X on Latitude E6530

[Thomas Vaughan]

I have attached the output both for linux-3.16 (which seems to have no
problem) and for linux-4.9.

On Thu, Feb 16, 2017 at 8:01 PM, Ben Hutchings <b...@decadent.org.uk> wrote:

> On Fri, 2017-02-17 at 02:26 +0000, Thomas Vaughan wrote:
> > No, I'm using only the free-software drivers.
> >
> > What's a bit odd is that both mode-setting (for Intel gpu) and nouveau
> (for
> > nvidia gpu) are used when I am docked (because of Optimus feature of
> > laptop).
> >
> > But problem shows when either docked or not.
> >
> > Problem appeared with Linux-4.9. There was no problem with Linux-4.8;
> > bummer when Linux-4.8 disappeared from the Debian repositories.
> >
> > What counts as out-of-tree?
>
> Anything that's not part of the linux-image-* packages.
>
> Can you just send the output of:
>
> cut -d' ' -f1,7 /proc/modules | sed 's/ //'
>
> Ben.
>
> --
> Ben Hutchings
> Any sufficiently advanced bug is indistinguishable from a feature.
>



-- 
Thomas E. Vaughan
rfcomm
fuse
vmw_vsock_vmci_transport
vsock
vmw_vmci
pci_stub
vboxpci(O)
vboxnetadp(O)
vboxnetflt(O)
vboxdrv(O)
snd_hrtimer
snd_seq
snd_seq_device
cpufreq_stats
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
bnep
binfmt_misc
x86_pkg_temp_thermal
intel_powerclamp
intel_rapl
coretemp
ecb
kvm_intel
btusb
bluetooth
6lowpan_iphc
kvm
wl(PO)
nouveau
iTCO_wdt
crc32_pclmul
i915
iTCO_vendor_support
dell_wmi
sparse_keymap
mxm_wmi
ttm
aesni_intel
aes_x86_64
lrw
dell_laptop
drm_kms_helper
joydev
evdev
gf128mul
drm
glue_helper
dcdbas
serio_raw
cfg80211
snd_hda_codec_idt
snd_hda_codec_generic
rfkill
ablk_helper
i2c_algo_bit
sg
pcspkr
snd_hda_intel
cryptd
wmi
snd_hda_controller
snd_hda_codec
snd_hwdep
snd_pcm
snd_timer
video
lpc_ich
mfd_core
mei_me
mei
snd
soundcore
shpchp
button
processor
ac
battery
dell_smo8800
parport_pc
ppdev
lp
sunrpc
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
sd_mod
sr_mod
crc_t10dif
crct10dif_generic
cdrom
ata_generic
mmc_block
crct10dif_pclmul
crct10dif_common
crc32c_intel
ata_piix
psmouse
libata
i2c_i801
sdhci_pci
i2c_core
scsi_mod
sdhci
ehci_pci
mmc_core
ehci_hcd
xhci_hcd
e1000e
ptp
usbcore
pps_core
usb_common
thermal
thermal_sys
fuse
vmw_vsock_vmci_transport
vsock
vmw_vmci
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
snd_hrtimer
snd_seq
snd_seq_device
cpufreq_conservative
cmac
cpufreq_userspace
cpufreq_powersave
bnep
binfmt_misc
btusb
btrtl
btbcm
btintel
bluetooth
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
wl(POE)
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
intel_cstate
nouveau
dell_wmi
sparse_keymap
iTCO_wdt
iTCO_vendor_support
intel_uncore
dell_laptop
intel_rapl_perf
dell_smm_hwmon
i915
dell_smbios
dcdbas
snd_hda_codec_idt
mxm_wmi
snd_hda_codec_generic
snd_hda_intel
ttm
mei_me
mei
cfg80211
snd_hda_codec
snd_hda_core
snd_hwdep
pcspkr
tpm_tis
evdev
joydev
snd_pcm
snd_timer
snd
drm_kms_helper
drm
lpc_ich
mfd_core
serio_raw
sg
wmi
soundcore
video
i2c_algo_bit
tpm_tis_core
shpchp
button
dell_smo8800
tpm
ac
dell_rbtn
rfkill
battery
sunrpc
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
ecb
mbcache
sr_mod
cdrom
sd_mod
ata_generic
mmc_block
crc32c_intel
aesni_intel
aes_x86_64
ata_piix
glue_helper
xhci_pci
lrw
psmouse
gf128mul
i2c_i801
xhci_hcd
ablk_helper
libata
i2c_smbus
cryptd
ehci_pci
ehci_hcd
sdhci_pci
e1000e
scsi_mod
sdhci
usbcore
mmc_core
ptp
pps_core
usb_common
thermal
fjes

Bug#853100: linux-image-4.9.0-1-amd64: Blocked tasks and no X on Latitude E6530

[Thomas Vaughan]

No, I'm using only the free-software drivers.

What's a bit odd is that both mode-setting (for Intel gpu) and nouveau (for
nvidia gpu) are used when I am docked (because of Optimus feature of
laptop).

But problem shows when either docked or not.

Problem appeared with Linux-4.9. There was no problem with Linux-4.8;
bummer when Linux-4.8 disappeared from the Debian repositories.

What counts as out-of-tree?

On Thu, Feb 16, 2017 at 20:08 Ben Hutchings <b...@decadent.org.uk> wrote:

> Control: tag -1 moreinfo
>
> On Sun, 29 Jan 2017 11:37:16 -0700 Thomas Vaughan <tevaug...@gmail.com>
> wrote:
> > Package: src:linux
> > Version: 4.9.2-2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Ever since linux-image-4.9.0-amd64 showed up in unstable, I've been
> unable to
> > use it on my laptop, a Dell Latitude E6530.
> >
> > After boot, the display manager never shows the X login screen.
> >
> > Eventually, I see messages like the following:
> >
> > INFO: task worker/1:1:68 blocked for more than 120 seconds
> >   Tainted: P OE  4.9.0-1-amd64 #1
> > INFO: task Xorg:837 blocked for more than 120 seconds
> >   Tainted: P OE  4.9.0-1-amd64 #1
> [...]
>
> Are you using the proprietary nvidia driver?  If not, what are the out-
> of-tree drivers you are using?
>
> Ben.
>
> --
> Ben Hutchings
> Any sufficiently advanced bug is indistinguishable from a feature.
>
> --
Thomas E. Vaughan

Bug#853100: Classification of Bug

[Thomas Vaughan]

When I submitted this bug report, I classified it as "normal".

But I suspect that it is graver than that. My system is currently unusable
with the kernel in testing and the kernel in unstable.

Only by pulling the ancient kernel from stable can I use my system at all.

-- 
Thomas E. Vaughan

Bug#853192: xfce4-panel: Aspect ratio of workspace switcher is wrong under Compiz.

[Thomas Vaughan]

Package: xfce4-panel
Version: 4.12.1-2
Severity: normal

Dear Maintainer,

Now that Compiz is back in unstable, I am using it again. I prefer to use
Compiz with XFCE.

However, under Compiz the workspace switcher has the wrong aspect ratio for
each workspace.

Apparently, this is a bug reported upstream.
https://bugzilla.xfce.org/show_bug.cgi?id=11697

I am reporting it here because there is a patch in that report, and Arch Linux
even has a modified package for the XFCE panel.
https://aur.archlinux.org/packages/xfce4-panel-compiz/

It would be cool if Debian could fix this problem, as Arch has, until upstream
fixes it.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages xfce4-panel depends on:
ii  exo-utils0.10.7-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.14-1
ii  libdbus-glib-1-2 0.108-2
ii  libexo-1-0   0.10.7-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgarcon-1-00.4.0-2
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libglib2.0-0 2.50.2-2
ii  libgtk2.0-0  2.24.31-2
ii  libice6  2:1.0.9-1+b1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libsm6   2:1.2.2-1+b1
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#853100: linux-image-4.9.0-1-amd64: Blocked tasks and no X on Latitude E6530

[Thomas Vaughan]

Package: src:linux
Version: 4.9.2-2
Severity: normal

Dear Maintainer,

Ever since linux-image-4.9.0-amd64 showed up in unstable, I've been unable to
use it on my laptop, a Dell Latitude E6530.

After boot, the display manager never shows the X login screen.

Eventually, I see messages like the following:

INFO: task worker/1:1:68 blocked for more than 120 seconds
  Tainted: P OE  4.9.0-1-amd64 #1
INFO: task Xorg:837 blocked for more than 120 seconds
  Tainted: P OE  4.9.0-1-amd64 #1

That pair of messages repeats a few times on the console.

I was unable to run reportbug successfully under linux-image-4.9.0.  I could get
through the first several reportbug questions, but it never launched the
editor.

Also, I cannot reboot from linux-image-4.9.0. Instead I have to hold down the
power button until pwer cuts off.

To make this report, I had to install the kernel from stable.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Latitude E6530
product_version: 01
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: A11
board_vendor: Dell Inc.
board_name: 07Y85M
board_version: A01

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM 
Controller [8086:0154] (rev 09)
Subsystem: Dell 3rd Gen Core processor DRAM Controller [1028:0535]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core 
processor PCI Express Root Port [8086:0151] (rev 09) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core 
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Dell 3rd Gen Core processor Graphics Controller [1028:0535]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Dell 7 Series/C210 Series Chipset Family USB xHCI Host 
Controller [1028:0535]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_hcd

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216 
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Dell 7 Series/C216 Chipset Family MEI Controller [1028:0535]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
Connection [8086:1502] (rev 04)
Subsystem: Dell 82579LM Gigabit Network Connection [1028:0535]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset Family 
USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI])
Subsystem: Dell 7 Series/C216 Chipset Family USB Enhanced Host 
Controller [1028:0535]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset Family 
High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Dell 7 Series/C216 Chipset Family High Definition Audio 
Controller [1028:0535]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 

Bug#849104: compizconfig-settings-manager should depend on libprotoc9v5

[Thomas Vaughan]

I figured out what my problem is.

I had built compiz some months ago from source and installed it under
/usr/local.

There was still some python stuff under there, and the new ccsm python
script was importing the compizconfig module from under /usr/local, which
is apparently in the python path first.

When I built ccsm, it must have depended on the old protobuf stuff.

So this is totally not a bug in the package dependencies.

Sorry for the noise.

​By the way, I am really happy that compiz is back in Debian!

I am a bit worried that I won't be able to use it, or that there will be
not decent replacement for it, when it finally happens that I am forced to
use wayland.​

Right now, I'm using compiz with xfce4.

-- 
Thomas E. Vaughan

Bug#849104: compizconfig-settings-manager should depend on libprotoc9v5

[Thomas Vaughan]

After uninstalling libprotoc9v5, I ran 'ccsm' from the command line and got
this:

Traceback (most recent call last):
  File "/usr/bin/ccsm", line 93, in 
import compizconfig
ImportError: libprotobuf.so.9: cannot open shared object file: No such file
or directory

$ dpkg -l '*compiz*' | grep ii | awk '{print $2 "   " $3}'
compiz   1:0.9.13.0+16.10.20160818.2-4
compiz-core   1:0.9.13.0+16.10.20160818.2-4
compiz-gnome   1:0.9.13.0+16.10.20160818.2-4
compiz-plugins   1:0.9.13.0+16.10.20160818.2-4
compiz-plugins-default   1:0.9.13.0+16.10.20160818.2-4
compizconfig-settings-manager   1:0.9.13.0+16.10.20160818.2-4
libcompizconfig0   1:0.9.13.0+16.10.20160818.2-4
python-compizconfig   1:0.9.13.0+16.10.20160818.2-4

​Apparently, when I tried to report the version number, is was truncated
because I took it from the output of 'dpkg -l
compizconfig-settings-manager', but, when its output be not piped to
another tool, dpkg constrains the column size by the terminal size. Sorry
about that.​

-- 
Thomas E. Vaughan

Bug#849097: compizconfig-settings-manager should depend on libprotoc9v5

[Thomas Vaughan]

Package: compizconfig-settings-manager
Version: 1:0.9.13.0+16.10.20160

Because libprotoc9v5 is not selected by apt on installation of
compizconfig-settings-manager, running the ccsm executable, which is linked
against that library, fails.

-- 
Thomas E. Vaughan

Bug#776171: same problem

[Thomas Vaughan]

On Sun, 10 Jul 2016 15:36:57 +0200 Michael Biebl  wrote:
> Control: tags -1 + moreinfo
>
> Hi
>
> Am 25.02.2016 um 10:26 schrieb Vincent Bernat:
> >
> > Same problem here. Any poweroff, reboot, suspend targets answer with the
> > same message. Absolutely no clue how to debug this...
>
> Which systemd version do you use? Is this problem reproducible (on a
> current sid system)?

​I am seeing this "transaction is destructive" message still whenever,
after starting up my laptop docked, I try to do a shutdown.

When docked with lid closed, the machine is incapable of shutting down
normally.  If I log in as root and type 'poweroff', that's when I see
"transaction is destructive".

I run Debian sid, updated daily.

I think that this problem has existed for me ever since the forced
transition to systemd months and months ago.

This problem has tempted me to look at Devuan, but I have so far been too
lazy.

My work-around is to leave my laptop lid open when it is docked. However, I
don't like this because
(a) my keyboard grows needlessly ever dirtier with dust over the months, and
(b) the backlight is on and generates extra heat that I'd rather not inject
into my already-too-hot office.​

​Please help.​

​(I am using the stock '/etc/systemd/logind.conf'.​ I have tried mucking
with the various lid-switch settings, but nothing seems to work.)

​My machine is a Latitude E6530 with both Nvidia and Intel via Optimus.
When docked, I am using the proprietary Nvidia drivers via dkms.

Both Intel and Nvidia drivers are installed, and I manually switch between
them via the update-glx command when I transition between docked and
undocked configuration.

--
​Thomas E. Vaughan
tevaug...@gmail.com​

Bug#776171: I See This Problem on Dell Latitude E6530 Laptop When Docked

[Thomas Vaughan]

When my laptop is docked and the lid closed, I see this problem: It is
impossible for me to shutdown (without holding the power button until power
is suddenly withdrawn from the system).

Running Debian sid with systemd-229-2.

When docked, my machine uses the NVIDIA kernel driver built via dkms.

I have no problem shutting down when either I leave the lid open on the
docking station or when the machine is undocked.

-- 
Thomas E. Vaughan

Bug#782077: Bug seems not fixed.

[Thomas Vaughan]

I am running a Dell E6530 with Debian unstable, lightdm (1.16.6-1) and
systemd (228-6).

If I don't keep the lid open when docked, then the system goes to sleep
before I can log in.

-- 
Thomas E. Vaughan

Bug#773057: I see same problem on Jessie.

[Thomas Vaughan]

Does anyone know what the problem is and/or have a work-around?



-- 
Thomas E. Vaughan

Bug#788575: liquidprompt seems to have been removed from unstable.

[Thomas Vaughan]

Yes. Liquidprompt seems to be in Debian unstable again this morning. Thanks!

On Mon, Jun 22, 2015 at 12:45 AM, Arturo Borrero Gonzalez
arturo.borrero.g...@gmail.com wrote:
 On 12 June 2015 at 22:41, Thomas Vaughan tevaug...@gmail.com wrote:
 Package: liquidprompt
 Version: 1.9-1

 After installing liquidprompt on its appearance in Debian unstable a
 day or two ago, I notice today that liquidprompt appears in the
 Obsolete and Locally Created Packages section in aptitude.

 I wrote to the maintainer, who asked me to open this bug report.

 I am using Debian unstable for amd64, updated daily.


 Hi,

 liquidprompt 1.9-2 has migrated recently from unstable to testing.
 This may indicate that the problem has been solved.
 Could you check if the issue is still there for you?

 Thanks, best regards.
 --
 Arturo Borrero González



-- 
Thomas E. Vaughan


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

Bug#788575: liquidprompt seems to have been removed from unstable.

[Thomas Vaughan]

Package: liquidprompt
Version: 1.9-1

After installing liquidprompt on its appearance in Debian unstable a
day or two ago, I notice today that liquidprompt appears in the
Obsolete and Locally Created Packages section in aptitude.

I wrote to the maintainer, who asked me to open this bug report.

I am using Debian unstable for amd64, updated daily.

-- 
Thomas E. Vaughan


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

Bug#741064: upstream fix

[Thomas Vaughan]

I agree that autofs-5.0.8, now in Debian unstable, is clearly broken.

Looking in what appears to be an upstream location (
https://www.kernel.org/pub/linux/daemons/autofs/v5/), I see evidence of
active, on-going development. There is not only an upstream version 5.0.9
that is mentioned in a previous post about the present bug but also an
upstream version 5.0.10, as well as what looks like a 5.1.x branch.

Both 5.0.10 and 5.1.1 seem to have been made available in 2014 Oct, just
last month as I write this.

Are these hopelessly broken, too? It seems as though an update to 5.0.10
might be in order.

What am I missing?

On Sun, Nov 16, 2014 at 12:44 PM, Michael Tokarev m...@tls.msk.ru wrote:

 16.11.2014 00:29, Thomas Vaughan wrote:
  On Fri, 14 Nov 2014 14:23:40 +0300 Michael Tokarev m...@tls.msk.ru
 mailto:m...@tls.msk.ru wrote:
 
  Sure, why not -- is `important' enough?  I'd like to make it RC
  so autofs is removed from debian finally, as it is just too
  broken
  ​.
 
  If autofs might be removed from Debian, then I have a question.
 
  Is there a different, less buggy package that I could install to get the
 same effect?
 
  What is the best practice?
 
  I have one machine at home with accounts for my wife and kids.
 
  I export the passwd file via nis.​
 
  ​I have another machine that they like to log into and still magically
 see all their stuff.
 
  How do I easily accomplish this in another way, without having to set up
 a bunch links and other brittle config on the non-master machine?​

 I for one don't know a way to do this.  There used to be amd (automount
 deaemon),
 but it looks like it is not mantained anymore.  There was autofs, but it
 is broken.

 Thanks,

 /mjt




-- 
Thomas E. Vaughan

Bug#741064: upstream fix

[Thomas Vaughan]

On Fri, 14 Nov 2014 14:23:40 +0300 Michael Tokarev m...@tls.msk.ru wrote:

 Sure, why not -- is `important' enough?  I'd like to make it RC
 so autofs is removed from debian finally, as it is just too
 broken
​.

If autofs might be removed from Debian, then I have a question.

Is there a different, less buggy package that I could install to get the
same effect?

What is the best practice?

I have one machine at home with accounts for my wife and kids.

I export the passwd file via nis.​

​I have another machine that they like to log into and still magically see
all their stuff.

How do I easily accomplish this in another way, without having to set up a
bunch links and other brittle config on the non-master machine?​
​

Bug#763925: dolphin: Documentation about changing directory in terminal panel incorrect.

[Thomas Vaughan]

Package: dolphin
Version: 4:4.14.1-1
Severity: minor
Tags: patch

Dear Maintainer,

Dolphin's on-line documentation, displayed in KDE's help application, states
that changing the directory in the Dolphin's Terminal Panel will not affect
Dolphin's GUI view. This is incorrect. Changing the directory in the terminal
*does* update the GUI view.

Here is a patch to fix (at least the English version of) the problem:

--begin patch--
--- /usr/share/doc/kde/HTML/en/dolphin/index.docbook2014-08-31
16:06:18.0 -0600
+++ /usr/share/doc/kde/HTML/en/dolphin/index.docbook.fixed
2014-10-03 13:44:49.997534428 -0600
@@ -747,9 +747,9 @@
 para
 This panel contains a terminal. The terminal will open at the folder currently
 shown in the dolphin; view. Changing the folder in the active dolphin;
-view will update the working folder of the terminal. The terminal only
-works with local media. Note: Changing folder in the terminal will not
-affect the dolphin; view.
+view will update the working folder of the terminal. Changing the directory in
+the terminal will update the working folder in the dolphin; view.  The
+terminal only works with local media.
 /para

 /sect2
--end patch--

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

Kernel: Linux 3.16-2-amd64 (SMP w/8 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 dolphin depends on:
ii  kde-runtime4:4.14.1-1
ii  libbaloocore4  4:4.14.1-1
ii  libbaloofiles4 4:4.14.1-1
ii  libbaloowidgets4   4:4.14.0-1
ii  libc6  2.19-11
ii  libkactivities64:4.13.3-1
ii  libkcmutils4   4:4.14.1-1
ii  libkdecore54:4.14.1-1
ii  libkdeui5  4:4.14.1-1
ii  libkfile4  4:4.14.1-1
ii  libkfilemetadata4  4:4.14.0-1+b2
ii  libkio54:4.14.1-1
ii  libknewstuff3-44:4.14.1-1
ii  libkonq5abi1   4:4.14.1-1
ii  libkparts4 4:4.14.1-1
ii  libphonon4 4:4.8.0-3
ii  libplasma3 4:4.14.1-1
ii  libqt4-dbus4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtgui4  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libsolid4  4:4.14.1-1
ii  libstdc++6 4.9.1-16
ii  libxrender11:0.9.8-1
ii  phonon 4:4.8.0-3

Versions of packages dolphin recommends:
ii  ruby  1:2.1.0.4

Versions of packages dolphin suggests:
ii  kdesdk-dolphin-plugins  4:4.13.3-1

-- no debconf information

-- 
Thomas E. Vaughan


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

Bug#761405: ruby2.1: Vector cross product in standard library is broken.

[Thomas Vaughan]

Package: ruby2.1
Version: 2.1.2-4
Severity: normal
Tags: upstream

In porting some three-dimensional-vector code from perl to ruby, I noticed that
the Vector class in ruby-2.1's standard library is broken. It returns a vector
that points in the opposite direction from that of the proper return value.

For example, witness this:

$ irb
irb(main):001:0 require 'matrix'
= true
irb(main):002:0 Vector[1,0,0].cross_product Vector[0,1,0]
= Vector[0, 0, -1]

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages ruby2.1 depends on:
ii  libc6 2.19-10
ii  libgmp10  2:6.0.0+dfsg-6
ii  libruby2.12.1.2-4
ii  rubygems-integration  1.8

Versions of packages ruby2.1 recommends:
ii  libjs-jquery  1.7.2+dfsg-3.2

ruby2.1 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#761405: ruby2.1: patch

[Thomas Vaughan]

Package: ruby2.1
Version: 2.1.2-4
Followup-For: Bug #761405

Here is a patch that fixes the problem.

$ diff -u /usr/lib/ruby/2.1.0/matrix.rb matrix.rb 
--- /usr/lib/ruby/2.1.0/matrix.rb   2014-05-08 09:46:50.0 -0600
+++ matrix.rb   2014-09-13 10:38:50.0 -0600
@@ -1764,9 +1764,9 @@
   #
   def cross_product(v)
 Vector.Raise ErrDimensionMismatch unless size == v.size  v.size == 3
-Vector[ v[1]*@elements[2] - v[2]*@elements[1],
-v[2]*@elements[0] - v[0]*@elements[2],
-v[0]*@elements[1] - v[1]*@elements[0] ]
+Vector[ @elements[1]*v[2] - @elements[2]*v[1],
+@elements[2]*v[0] - @elements[0]*v[2],
+@elements[0]*v[1] - @elements[1]*v[0] ]
   end
 
   #


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages ruby2.1 depends on:
ii  libc6 2.19-10
ii  libgmp10  2:6.0.0+dfsg-6
ii  libruby2.12.1.2-4
ii  rubygems-integration  1.8

Versions of packages ruby2.1 recommends:
ii  libjs-jquery  1.7.2+dfsg-3.2

ruby2.1 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#761405: ruby2.1: Vector cross product in standard library is broken.

[Thomas Vaughan]

Package: ruby2.1
Version: 2.1.2-4
Followup-For: Bug #761405

I answered a question about this over at StackOverflow.

http://stackoverflow.com/questions/23831320/why-ruby-cross-product-returns-different-value-from-cross-product-on-paper/

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages ruby2.1 depends on:
ii  libc6 2.19-10
ii  libgmp10  2:6.0.0+dfsg-6
ii  libruby2.12.1.2-4
ii  rubygems-integration  1.8

Versions of packages ruby2.1 recommends:
ii  libjs-jquery  1.7.2+dfsg-3.2

ruby2.1 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#761405: ruby2.1: Vector cross product in standard library is broken.

[Thomas Vaughan]

Ok. I'll do that.

Sent from my iPhone

 On Sep 13, 2014, at 11:30, Christian Hofstaedtler z...@debian.org wrote:
 
 Thank you for reporting this bug and the patch.
 Could you possibly report this in the upstream bug tracker, too?
 
 Best,
  Christian
 
 -- 
 ,''`.  Christian Hofstaedtler z...@debian.org
 : :' :  Debian Developer
 `. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-
 


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

Bug#721778: doxygen: Doxygen in unstable seems not to be compiled against libclang.

[Thomas Vaughan]

This seems to be a different link to the same discussion:

http://clang-developers.42468.n3.nabble.com/Doxygen-1-8-4-uses-libclang-to-improve-parsing-td4032204.html

I can't speak to the question about failure to build from source, but
Doxygen's call and called-by trees are unusable for my C++ projects because
Doxygen does not handle overloading well. With libclang support there seems
to be hope that the trees will be right, and I could then turn them on in
the Doxygen output.


On Sun, Jan 5, 2014 at 5:09 PM, Matthias Klose d...@debian.org wrote:

 Am 04.09.2013 01:47, schrieb Thomas E. Vaughan:
  Package: doxygen
  Version: 1.8.4-1
  Severity: normal
 
  Dear Maintainer,
 
  It seems that doxygen in unstable does not depend on
  libclang even though it is at least at version 1.8.4.  It
  would be cool to try out the improved parsing available via
  clang.
 
  http://comments.gmane.org/gmane.comp.compilers.clang.devel/29490

 404

  Could you compile in support for libclang?

 how well is this tested?  how many packages will ftbfs in unstable?

   Matthias




-- 
Thomas E. Vaughan

Bug#727698: More Information

[Thomas Vaughan]

In an activity completely unrelated to IMAP or dovecot, I tried changing
the password of an account on the same machine as my dovecot IMAP server.

As root, I typed 'passwd foo' to change the password of the foo account.

As soon as I pressed ENTER, the system printed, no talloc stackframe at
../source3/param/loadparm.c:4831, leaking memory, just before the line,
Enter new UNIX password:.

So it seems that dovecot is getting the string from a noisy, external
authentication system and passing that string along to the system log.

Googling around, I find that this might be related to a recent change in
samba.

https://lists.samba.org/archive/samba/2012-August/168869.html

-- 
Thomas E. Vaughan

Bug#664706: libreoffice-report-builder: report-builder exception and rollback

[Thomas Vaughan]

Package: libreoffice-report-builder
Version: 1:1.2.1+Lib03.4.6-2
Followup-For: Bug #664706

Dear Maintainer,

I keep three machines up to date with unstable. The two that
are amd64 architecture have no problem, but the one that is
i686 architecture does show this problem.

Unfortunately the i686 machine is the one that *needs* to
have report-builder installed. Even more unfortunately, both
unstable *and* testing show this problem. So I've
uninstalled libreoffice and instead installed the
openoffice.org packages from stable.

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

Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core)
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 libreoffice-report-builder depends on:
pn  gcj-4.6-jre [java5-runtime]4.6.3-1
pn  gcj-jre [java5-runtime]4:4.6.2-4
pn  libbase-java   none
pn  libcommons-logging-java1.1.1-8
pn  libflute-java  none
pn  libfonts-java  none
pn  libformula-javanone
pn  liblayout-java none
pn  libloader-java none
pn  libpentaho-reporting-flow-engine-java  none
pn  libreoffice-core   none
pn  libreoffice-java-commonnone
pn  libreoffice-report-builder-bin none
pn  librepository-java none
pn  libsac-java1.3-3
pn  libserializer-java none
pn  libxml-javanone

libreoffice-report-builder recommends no packages.

libreoffice-report-builder suggests no packages.



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

Bug#529732: An octave-quaternion package would be really nice!

[Thomas Vaughan]

Right now, I'm installing the quaternion package by hand because it seems
not to be packaged for Debian.

-- 
Thomas E. Vaughan

Bug#615598: I've seen something like this, too.

[Thomas Vaughan]

I've seen a similar problem, with the EDID complaint every so often,
on a machine with Intel graphics, with each of 2.6.37-1 and 2.6.37-2.
This machine's graphics continue to work.

-- 
Thomas E. Vaughan



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

Bug#608411: libgnome-desktop-2-17: Span style for desktop background doesn't zoom.

[Thomas Vaughan]

On Thu, Dec 30, 2010 at 16:59, Josselin Mouette j...@debian.org wrote:
 Le jeudi 30 décembre 2010 à 10:31 -0700, Thomas E. Vaughan a écrit :
 The problem is that, unless the image has *exactly* the
 right dimensions, there will be constant-color bars in the
 background on either side of the multi-monitor background.

 Well, that’s the meaning of “span”. If you want the picture to be
 zoomed, use the “zoom” style.

No, I think that you have it wrong.

The Zoom style zooms independently for each monitor, so that you have
two copies of the image in the overall display.

The Span style is intended to span the same image across multiple
monitors, so that each monitor shows a different portion of the same
background image.

The problem is that the Span style is not properly implemented. It
should use the zoom functionality, but applied to the whole desktop
(area of all monitors). That's what my patch does, and it works
beautifully. You should test the behavior both with and without the
patch on a dual-monitor system to see what I mean. Pick a background
image that doesn't happen to be exactly the dimension of the overall
desktop.

 --- gnome-desktop-2.30.2/libgnome-desktop/gnome-bg.c.orig     2010-12-30 
 10:13:04.0 -0700
 +++ gnome-desktop-2.30.2/libgnome-desktop/gnome-bg.c  2010-12-30 
 09:45:52.0 -0700
 @@ -748,7 +748,7 @@

       switch (placement) {
       case GNOME_BG_PLACEMENT_SPANNED:
 -                new = pixbuf_scale_to_fit (pixbuf, width, height);
 +                new = pixbuf_scale_to_min (pixbuf, width, height);
               break;
       case GNOME_BG_PLACEMENT_ZOOMED:
               new = pixbuf_scale_to_min (pixbuf, width, height);
                        ^^^
 See? In zoom style it already behaves as you want it to.

No, there is code elsewhere in the file that guarantees that these two
cases do not produce the same results when my patch is applied. Try it
out; don't just assume that you know what will happen.

-- 
Thomas E. Vaughan

For not everything does have a final cause, given the existence of
chance events. What Aquinas actually says, as we have seen, is that
every *agent* has a final cause; that is to say, that everything that
serves as an efficient cause points to or is directed at some specific
effect or range of effects as its natural end.

(From _Aquinas: A Beginner's Guide_ by Edward Feser)



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

Bug#567832: linux-image-2.6.32-trunk-686: soft lockup - CPU#0 stuck inside Virtualbox

[Thomas Vaughan]

Thanks, Jeff.

On Thu, Aug 5, 2010 at 07:37, Fleck, Jeff jfl...@ball.com wrote:
 Looks like they fixed the problem. I updated to the latest linux-image and 
 linux-headers and everything seems to be working. I completely shut down my 
 computer and when I re-started virtualbox everything came up with no problems.

 Jeff

 -Original Message-
 From: Thomas Vaughan [mailto:tevaug...@gmail.com]
 Sent: Sunday, August 01, 2010 8:45 PM
 To: Fleck, Jeff
 Subject: Fwd: linux-image-2.6.32-trunk-686: soft lockup - CPU#0 stuck 
 inside Virtualbox

 Could you report on this. I filed a bug report when you showed me the
 weird behavior at boot time. I know that you found a work-around, but
 the powers that be want to know if there is still a problem with the
 latest kernel in Debian. You might just upgrade the kernel (and
 VirtualBox) to the latest, and see what happens. It would be cool if
 the problem is gone. Otherwise, I (or perhaps you) should indicate
 that the problem remains.

 -- Forwarded message --
 From: Moritz Muehlenhoff j...@inutil.org
 Date: Sun, Aug 1, 2010 at 16:24
 Subject: Re: linux-image-2.6.32-trunk-686: soft lockup - CPU#0 stuck
 inside Virtualbox
 To: Thomas E. Vaughan tevaug...@gmail.com
 Cc: 567...@bugs.debian.org, cont...@bugs.debian.org


 tags 567832 moreinfo
 thanks

 On Sun, Jan 31, 2010 at 10:00:52AM -0700, Thomas E. Vaughan wrote:
 Package: linux-2.6
 Version: 2.6.32-5
 Severity: normal


 As the guest inside Virtualbox,
 'linux-image-2.6.32-trunk-686' hangs at boot with the
 following message:

 BUG: soft lockup - CPU#0 stuck for 61s! [modprobe:95]

 The message is repeated about once per minute, apparently
 indefinitely.

 The older kernel 'linux-image-2.6.30-686' does boot
 successfully.

 Does this still occur with the current sid kernel in both
 the host and the guest?

 Cheers,
        Moritz



 --
 Thomas E. Vaughan

 There are only two kinds of people; those who accept dogma and know
 it, and those who accept dogma and don't know it. - G.K. Chesterton



 This message and any enclosures are intended only for the addressee.  Please
 notify the sender by email if you are not the intended recipient.  If you are
 not the intended recipient, you may not use, copy, disclose, or distribute 
 this
 message or its contents or enclosures to any other person and any such actions
 may be unlawful.  Ball reserves the right to monitor and review all messages
 and enclosures sent to or from this email address.




-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know
it, and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#542701: xserver-xorg-video-intel: Very slow 2D performance on one screen of dual display until after switch to console VT and back.

[Thomas Vaughan]

On Sun, Feb 28, 2010 at 4:36 PM, Cyril Brulebois k...@debian.org
wrote:

 Carl Worth cwo...@cworth.org (03/09/2009):
 
  Thomas Vaughan wrote:
  
   By the way, I don't mind grabbing the relevant source and building
   for debug output, if that would be of any help.  I just need to
   know how to turn on the relevant output or else where to stick
   some printf()s.
 
  If you're interesting in building things, one thing you might do is
  to build a recent kernel and use kernel modesetting, (load the i915
  module with the option modeset=1 either on the modprobe command
  line or by putting i915 modeset=1 into /etc/modules). It would be
  interesting to hear if the behavior is identical with a KMS setup.

 you should find everything you'd need to test Carl's suggestion in
 unstable, where KMS is automatically enabled. You can check the
 details about kernel versions in the second part of this blogpost:

 http://ikibiki.org/blog/2010/02/28/Where_have_you_been/

Thanks for contacting me.

I never followed up on this because the hardware configuration at my
office changed. I still do have the machine with the 82945 video
adapter, but it now has only a single monitor attached, and I'm using
that machine at this point only to serve files.

If there be a ticket open somewhere only because I noticed an anomaly
that no one else cares about, then one might feel free to close it, even
if it be a real anomaly. I don't want to be a source of trouble. :^)

The point is that the 82945 can be made to drive a pair of displays,
each at 1600x1200, with hardware-accelerated 3D.

I got it to work.

Unfortunately, after X started, I had to switch to the text VT and back
to the X screen in order to get the second screen not to be really
sluggish.

Anyway, I don't have time to play with it, at least not for the next few
weeks.

Your message seems to indicate that it should be easy for me to test KMS
now that Debian unstable has everything available for free by default.

That is an interesting bit of news, and so I might get around to playing
with it next month some time.

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#542701: xserver-xorg-video-intel: Very slow 2D performance on one screen of dual display until after switch to console VT and back.

[Thomas Vaughan]

On Thu, Sep 3, 2009 at 12:02 PM, Carl Worthcwo...@cworth.org wrote:

 Hi Thomas,

Hello, Carl,

Thanks for taking the time to contact me.  :^)

 You've got a very mysterious bug.

Well, at least I have a reliable work-around.

 The acceleration code in the driver isn't aware of the two different
 monitors at all, (it's just seeing coordinates).

 I discussed the problem with a room full of graphics engineers and
 mostly got head scratching.

I'm glad that I noticed something that might serve at least as an
interesting puzzle.

 But there was one germ of an idea: Perhaps there's some odd RandR
 transformation being configured for the one display. (For example,
 imagine the code going through an extra copy and transformation as if
 rotated.) Something like that might cause the slowdown.

That seems plausible to me.  A few months ago I played with
rotating one of my monitors, but the performance was so bad that I
stopped playing with it.  Anyway, the performance problem that I saw
with my rotated monitor was of exactly the same kind that I see on the
right screen before the VT switch.  Not that this proves anything.

 And doing the VT switch might get your desktop environment to
 reconfigure the RandR stuff correctly the second time.

 That's not much of a theory, but you might poke around to see if the
 output of xrandr changes from before to after the VT switch.

The output of 'xrandr --verbose' was identical from before to after the
VT switch.  I diffed the results and got null output.  I'll attach one
of the output files.

 You might also try running with a different desktop environment (or
 none at all) to see if the buggy behavior changes at all.

I recently switched from gnome to kde, but this of course makes no
difference.  I can see that the right screen is painted slowly even when
gdm (or kdm) initializes itself at startup.

Moreover, I've done most of my testing by just killing the display
manager and starting X with xinit, and then doing 'twm ' at the shell
prompt in xterm.  The clearest test in that case is just to drag the
xterm window from the left screen to the right screen.  The twm window
manager just draws an outline while dragging, but even this outline is
noticeably distorted by motion on the right screen, whereas it is hardly
distorted at all on the left.

By the way, do you have access to hardware on which this anomaly can be
reproduced?

It would be nice to know that I am not continually suffering from the
same hallucination over and over again.  :^)

By the way, I don't mind grabbing the relevant source and building for
debug output, if that would be of any help.  I just need to know how to
turn on the relevant output or else where to stick some printf()s.

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton


xrandr-output-before-switch
Description: Binary data

Bug#542701: xserver-xorg-video-intel: Very slow 2D performance on one screen of dual display until after switch to console VT and back.

[Thomas Vaughan]

On Thu, Aug 20, 2009 at 4:45 PM, Brice Goglinbrice.gog...@ens-lyon.org
wrote:

 Thomas E. Vaughan wrote:
 
  Package: xserver-xorg-video-intel
  Version: 2:2.8.0-2

By the way, the behavior is still the same with 2:2.8.1-1.

  When the X server first starts up, 2D performance (such as painting
  the background, dragging a window, etc.) is nice and fast on my left
  monitor (VGA) but very slow on my right monitor (TMDS-1).

I have also now verified that 3D performance is initially slow, too, on
the right monitor (whether it be VGA or TMDS-1) but the sluggishness of
3D when 2D is sluggish doesn't seem particularly surprising.

 By the way, it looks like you're getting a 3200x1200 virtual screen.
 It may be larger 3D coordinates than what your board supports IIRC.
 Does it help if you reduce both monitors' resolution to 1024x768
 instead of 1600x1200 ?

Yes, at 2048x768, the initial condition is fully accelerated for 2D and
3D.

At 2560x1024 and 3200x1200, the initial condition is for the right
monitor to be slow for 2D and 3D.

After I do a VT switch via CTRL-ALT-F1 and back (ALT-F7), both 2D and 3D
are fully accelerated on the right monitor, at 2560x1024 and at
3200x1200.  For example, after switching to the console and back, I can
maximize glxgears on either screen and get about 300 FPS at 3200x1200.
Before switching, the right screen gets something abysmal on the order
of 10 FPS.

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#542701: xserver-xorg-video-intel: Very slow 2D performance on one screen of dual display until after switch to console VT and back.

[Thomas Vaughan]

On Thu, Aug 20, 2009 at 4:45 PM, Brice Goglinbrice.gog...@ens-lyon.org
wrote:

 What happens if you swap monitors' positions? Does the slowness follow
 TMDS?

No.

That is, when I leave everything unchanged in 'xorg.conf' except for
changing RightOf to LeftOf in the Monitor section for what was the
right monitor, the initial sluggishness moves to the VGA output.

So when the X server fires up, whichever output is designated as being
on the right is the one that is slow for window dragging, etc.

Again, switching to a console VT and back clears up the problem.

 By the way, it looks like you're getting a 3200x1200 virtual screen.

Yes, I am, and this started working only recently.  Aside from the
initial sluggishness on the right screen, however, I've seen no problem
whatsoever.

 It may be larger 3D coordinates than what your board supports IIRC.

I don't know if this be a good test, but I just ran glxgears, and I'm
getting no corruption on either screen, and I get about 300 FPS with
glxgears maximized on either screen.

 Does it help if you reduce both monitors' resolution to 1024x768
 instead of 1600x1200 ?

Are you wondering whether it helps the initial 2D sluggishness?

I don't know yet, but I'll try the experiment at some point and get back
to you.

By the way, thank you very much for taking the time to investigate
this with me.

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#542069: xserver-xorg-video-intel: Second screen (TMDS-1) not functioning after recent update to unstable.

[Thomas Vaughan]

On Thu, Aug 20, 2009 at 1:28 AM, Brice Goglinbrice.gog...@ens-lyon.org
wrote:

 Any idea if you had xserver-xorg-video-intel 2.7.1 before the upgrade?

Well, it seems that I was using 2.7.1 at least as late as July 02,
according to the date stamp on '/var/log/Xorg.1.log'.  There is an EDID
entry for each of my two monitors in the old log.

 You can try downgrading using packages from
 http://people.debian.org/~bgoglin/rebuilds/Xserver1.6/

Thanks.  I downgraded with your package and have 2.7.1 now installed
again, but I'm still seeing no EDID stuff for TMDS-1, whose attached
monitor is a member of the same species (model) as is the monitor
attached to VGA.

Do you know of any other updates that might have messed up the EDID
stuff for TMDS-1?  A kernel update?

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#542069: xserver-xorg-video-intel: Second screen (TMDS-1) not functioning after recent update to unstable.

[Thomas Vaughan]

On Thu, Aug 20, 2009 at 12:07 PM, Thomas Vaughantevaug...@gmail.com
wrote:

 Do you know of any other updates that might have messed up the EDID
 stuff for TMDS-1?  A kernel update?

I discovered the problem.

Please close this bug report 542069.

The connector at the monitor attached to TMDS-1 was seated well enough
to produce a video signal, as I saw at boot time.

Apparently, however, it was *not* seated well enough to provide the EDID
data.  I must have moved the monitor last week and disturbed an insecure
connection to produce my problem.

After reseating the connector, all is well.  I'm running the latest
unstable stuff right now.

By the way, after I restart the X server, I have to toggle via
CTRL-ALT-F1 to the linux console and then back (ALT-F7) again to X
windows in order to get my TMDS-1 screen to be fully accelerated.  If
anybody who sees this knows why, then please shoot me an e-mail.

Obviously, I have a manual work-around, but I'm interested in an
automatic work-around.

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#542069: xserver-xorg-video-intel: Second screen (TMDS-1) not functioning after recent update to unstable.

[Thomas Vaughan]

On Thu, Aug 20, 2009 at 12:57 PM, Carl Worthcwo...@cworth.org wrote:

 Beyond replicating the originally working software environment as well
 as possible, you can explore whether there's some other issue that
 could have affected things. For example, is it possible to switch
 cables from a working to a non-working monitor?

Thanks for all of the kind responses.  :^)

I did indeed figure out the problem by this method just before I
received your message.  Apparently, I had a connector that was seated
well enough to show video (at least at the linux console) but not well
enough to do the EDID communication needed by the X server to enable the
output.

Now my only remaining head-scratcher is why, after starting the X
server, I have to CTRL-ALT-F1 and then ALT-F7 back in order to get my
TMDS-1 output fully accelerated for window dragging, etc.

-- 
Thomas E. Vaughan

There are only two kinds of people; those who accept dogma and know it,
and those who accept dogma and don't know it. - G.K. Chesterton



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

Bug#466908: still starts too early

[Thomas Vaughan]

On Fri, Apr 11, 2008 at 8:23 AM, Jonny Lamb [EMAIL PROTECTED]
wrote:

 On Tue, Apr 08, 2008 at 08:57:33AM -0600, Thomas Vaughan wrote:
 
  odccm-0.11-3 still seems to start before hal.
 
  Anyway, there is a complaint about hal, and odccm doesn't start at
  boot time.  I still have to start it manually.

 I am not experiencing a problem with this any more. odccm starts fine
 (and *after* hald) on boot. What exactly are you experiencing, when,
 and after you do what?

My problem is at boot time.  I don't remember how to capture in a log
file a copy of the boot messages, but I do see a mention of hal in the
error message that odccm's start-up script issues.

 Something I have just noticed is that I might be stopping odccm after
 stopping hald, which is obviously flawed. Might this be a solution to
 your problem?

I think not.

tevaugha-lt $ find /etc/rc?.d -name '*odccm'
/etc/rc0.d/K20odccm
/etc/rc1.d/K20odccm
/etc/rc2.d/S20odccm
/etc/rc3.d/S20odccm
/etc/rc4.d/S20odccm
/etc/rc5.d/S20odccm
/etc/rc6.d/K20odccm

tevaugha-lt $ find /etc/rc?.d -name '*hal'
/etc/rc0.d/K16hal
/etc/rc1.d/K16hal
/etc/rc2.d/S24hal
/etc/rc3.d/S24hal
/etc/rc4.d/S24hal
/etc/rc5.d/S24hal
/etc/rc6.d/K16hal

So, hal is set to start *after* odccm in every run level.

tevaugha-lt $ dpkg -l odccm | grep ii | awk '{print $3}'
0.11-3

Now, I upgraded from 'odccm-0.11-2'.  Perhaps this would fix itself if I
were to uninstall odccm and then reinstall it.

Did you test upgrading from 'odccm-0.11-2' to see if the links into
'init.d' were modified properly?

-- 
Thomas E. Vaughan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466908: still starts too early

[Thomas Vaughan]

On Fri, Apr 11, 2008 at 11:37 AM, Jonny Lamb [EMAIL PROTECTED]
wrote:

 Your thoughts on the fix would also be appreciated.

I'm no expert on this stuff, but your fix seems consistent with the
documentation on the man page for 'update-rc.d'.

Moreover, I tested your fix, and it seems to work.  (I haven't rebooted
yet, but the links all look right now.)

 Sorry for the delay in getting this fixed and thank you for the
 information you have provided.

You need not apologize, and you are quite welcome.

Oh, and thanks for providing the package. :^)

Be well.

-- 
Thomas E. Vaughan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466908: still starts too early

[Thomas Vaughan]

On Fri, Apr 11, 2008 at 12:13 PM, Thomas Vaughan [EMAIL PROTECTED]
wrote:

  Your thoughts on the fix would also be appreciated.

 I'm no expert on this stuff, but your fix seems consistent with the
 documentation on the man page for 'update-rc.d'.

When I look closely at the man page, I find:

   If any files /etc/rcrunlevel.d/[SK]??name already exist then
   update-rc.d does nothing.  The program was written this way so that
   it will never change an existing configuration, which may have been
   customized by the system administrator.  The program will only
   install links if none are present, i.e., if it appears that the
   service has never been installed before.

I know that it's more work, but, in the spirit of the man page---and
with a view toward the highest standard of quality---you might consider
implementing in the postinst script the right Bourne shell code to
implement the following pseudocode, which would take the place of the
line that you inserted, which always forces removal of old links:

if upgrading from odccm version  0.11-3
  if links are as the old package installed them
force removal of old links
  else if links are not as odccm-0.11-3 would install them
complain about potentially bad local modification of links
suggest at least temporary manual removal of links
administrator might replace his links after installation if need be
exit with error from postinst
  endif
endif

-- 
Thomas E. Vaughan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466908: still starts too early

[Thomas Vaughan]

odccm-0.11-3 still seems to start before hal.

Anyway, there is a complaint about hal, and odccm doesn't start at boot
time.  I still have to start it manually.

-- 
Thomas E. Vaughan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#473469: need to restart dbus before starting odccm in postinst

[Thomas Vaughan]

Even if '/etc/dbus-1/system.d/odccm.conf' is installed, starting odccm
will not necessarily work.  To be sure that dbus picks up the conf file,
add

   /etc/init.d/dbus restart

early in 'odccm.postinst', before it starts oddcm.

-- 
Thomas E. Vaughan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]