colord[xxxxx]: failed to get session [pid yyyyy]: No data available
I've noticed this message about once per day just after midnight. Googling about it did not seem (to me) to produce anything definitive, but perhaps I did not try hard enough. Does anybody here know 1. why this is being printed to the system log 2. whether I should just tell logcheck to ignore it, or 3. whether I should do something to make it stop? -- Thomas E. Vaughan
odd message from upowerd and simultaneous death of xfce4-notifyd
Logcheck, running on a machine with up-to-date debian unstable, sent me the following in an email yesterday. (Times and machine name removed from beginning of each line.) upowerd[7393]: energy 99.90 bigger than full 91.652700 kernel: [345764.796963] xfce4-notifyd[2202]: segfault at 9 ip 7fcfb6a5c8ba sp 7ffe9f35d320 error 4+in libc-2.26.so (deleted)[7fcfb69df000+1ad000] systemd[2055]: xfce4-notifyd.service: Main process exited, code=killed, status=11/SEGV systemd[2055]: xfce4-notifyd.service: Failed with result 'signal'. 1. Does the upowerd message indicate that something is wrong? 2. Is the simultaneous death of xfce4-notifyd a mere coincidence? (All four messages have the same time stamp down to the second.) -- Thomas E. Vaughan
maxima, draw3d, and vtk
The 'draw3d' function defined in the 'draw' package for maxima is failing.
Before I file a bug report, I'd like to find out what package has the bug.
(Or find out if the bug be user error. :-)
I am running Debian unstable with maxima, vtk6, and tcl-vtk6 installed,
according to documentation here: http://riotorto.users.sourceforge.net/vtk/
The error output (pasted below) refers to a file that does not exist:
/usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so
Using 'dpkg -S libvtkCommonCoreTCL', I find
libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3.0
libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3
It looks to me as though there is something at least a bit broken about the
names of the libraries installed by the libvtk6.3 Debian package, but I'm
not an expert in library naming.
If you have an idea of what I might do to rectify the situation, then
please respond to all, because I am not a subscriber to the list.
Anyway, here is the error that I saw inside maxima:
(%i8) draw3d(color=white,elevation_grid(m,0,0,10,10));
(%o8)done
(%i9) couldn't load file "/usr/lib/x86_64-linux-gnu/
libvtkCommonCoreTCL-6.3.so": /usr/lib/x86_64-linux-gnu/
libvtkCommonCoreTCL-6.3.so: cannot open shared object file: No such file or
directory
attempt to provide package vtkCommonCoreTCL 6.3 failed: no version of
package vtkCommonCoreTCL provided
attempt to provide package vtkcommoncore 6.3 failed: no version of package
vtkcommoncore provided
Error in startup script: attempt to provide package vtk 6.3 failed: no
version of package vtk provided
("package ifneeded vtk 6.3" script)
invoked from within
"package.orig require vtk"
("eval" body line 1)
invoked from within
"eval package.orig $args"
(procedure "package" line 2)
invoked from within
"package require vtk"
--
Thomas E. Vaughan
Two Graphics Cards and Hardware-Accelerated OpenGL
At the moment, I have to reboot to MS Windows in order to take full advantage of all three of the monitors on my desk, but I'd usually rather not boot to MS Windows. I'd like to make it so that my monitor setup works as well under Debian. The dock for my Dell laptop has two DVI ports and a VGA port. The two DVI ports are driven by an Nvidia graphics device, and the VGA port is driven by an Intel graphics device. I have a monitor connected to each port. Yes, I have been able to configure 'xorg.conf' to enable Xinerama, and I can then use all three monitors. The problem is that, well, it's Xinerama, and so (1) I can't drag a window from one graphics subsystem to the other, and (2) OpenGL doesn't get hardware acceleration on every screen. However, everything just seems to work in a unified way under MS Windows. I have read that Wayland will enable the right solution. Is this right? If so, then is it possible, say, to run Debian unstable with KDE on top of Wayland rather than on top of X? That is, can I somehow get Wayland to unify the display produced by the two different graphics subsystems and then run something like KDE on top of it? Even now, on Debian unstable? Or is there another solution? -- Thomas E. Vaughan
Re: [Fwd: Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version]
What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. Yes you can, by getting the source code from kernel.org. If you simply copy the config from the Debians kernel, then IIRC # make-kpkg --initrd kernel-image kernel-headers won't use the Debians naming, but name the package and the output for uname -r and any string else as the original kernel.org name is. Thank you very much! That worked well and was easy! -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caao_ux-s-lz2rtcqmg1kjzdffzrmewogt7uwfyem1bpca03...@mail.gmail.com
Third-Party Software Needs Non-Debian Format for Kernel Version
I have downloaded some proprietary software that I want to install onto a 64-bit Debian machine. The software is written for 64-bit linux, but the kernel version reported, for example, by uname (and perhaps by some system call that the compiled software uses) is not in a format that the software expects. ---BEGIN QUOTE FROM VENDOR--- Its not that 3.12-1-amd64 isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? -- Thomas E. Vaughan
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? An appropriately named shell script in the right place in the path might take care of uname(1), but I don't see how to take care of uname(2), the system call. When the vendor says that the software parses the string, I think that the software is calling uname(). So my question is whether there is a way by compiling a custom kernel for me to alter what the uname() system call reports. -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caao_ux-kfd6odmkp0fzzznwdbm1kljy+mykbknl9wfd6+qy...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or link or what ever? I don't understand what the software is doing, that the output of uname -r doesn't fit to some other string. I think that the build system is using the uname(1) command, but the compiled software is calling the uname(2) system call. More information is needed. I have not very much information, but let's assume the worst: The vendor has some compiled code that calls the uname() system call. Is it possible by compiling a custom kernel for me to make what uname() returns be the format that the vendor desires, something like '3.12.9-1', or whatever? Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z, 3.x.n. I like this, since I don't need to manually fix my manually customized grub.cfg, when such a kernel is upgraded and especially those kernels are updated and older versions automatically will be removed, while kernels build by myself are never touched. I'm not sure that I understand. The package name is one thing, but isn't what uname returns something else? -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8TwPVzU-NmP==wyqe23gia4ukkpujtdgpdprtc1v_...@mail.gmail.com
Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
isn't supported per se. But when [the software], or the makefiles, parse the string 3.12-1-amd64 they don't get the expected result. If the uname -r were the string 3.12.9-1 then parsing it would yield the expected result. ---END QUOTE FROM VENDOR--- Is the reported kernel-version string, 3.12-1-amd64, something that I could change by compiling a custom kernel? Might a shell script that output the expected string work? Or sed? Or export? Or, um, more information about what Debian release is being used and the third-party software. :) If the compiled program calls the uname() system call, then script-related fixes won't work. I don't have the source to the compiled program. I'm running Debian testing (jessie). Kind regards And kind regards to you for replying so promptly to my plea for help! What I'm wondering is whether I can get uname to return the desired format by somehow compiling a custom kernel. If so, then any help doing that properly would be appreciated. -- Thomas E. Vaughan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAO_ux8P23JyZr3NyL_qR3K=0nzkeybr4vso9xsnj6+z_k-...@mail.gmail.com
Re: Help: 'g++ -m32 ...' does not find asm/socket.h
Thanks! That worked. On Thu, Jan 2, 2014 at 11:35 AM, Sven Joachim svenj...@gmx.de wrote: On 2014-01-02 19:22 +0100, Thomas Vaughan wrote: Using Debian unstable and default g++ (4.8.2), I am recently unable to build a project that was building a few weeks ago. ---BEGIN SNIPPET FROM BUILD LOG--- libtool: compile: g++ ... -m32 -fmessage-length=0 -O0 -fPIC -ggdb3 -fvar-tracking-assignments -W -Wall -Wconversion -Wshadow -Wcast-align -Wwrite-strings -Wpointer-arith -MT bar.lo -MD -MP -MF .deps/bar.Tpo -c bar.cpp -o bar.o In file included from /usr/include/sys/socket.h:39:0, from /usr/include/netinet/in.h:24, from /usr/include/arpa/inet.h:22, ... /usr/include/bits/socket.h:343:24: fatal error: asm/socket.h: No such file or directory #include asm/socket.h Install gcc-multilib, it includes the necessary symlink /usr/include/asm - x86_64-linux-gnu/asm for g++ -m32 to work. Cheers, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u0q6xl9@turtle.gmx.de -- Thomas E. Vaughan
Help: 'g++ -m32 ...' does not find asm/socket.h
Using Debian unstable and default g++ (4.8.2), I am recently unable to
build a project that was building a few weeks ago.
---BEGIN SNIPPET FROM BUILD LOG---
libtool: compile: g++ ... -m32 -fmessage-length=0 -O0 -fPIC -ggdb3
-fvar-tracking-assignments -W -Wall -Wconversion -Wshadow -Wcast-align
-Wwrite-strings -Wpointer-arith -MT bar.lo -MD -MP -MF .deps/bar.Tpo -c
bar.cpp -o bar.o
In file included from /usr/include/sys/socket.h:39:0,
from /usr/include/netinet/in.h:24,
from /usr/include/arpa/inet.h:22,
...
/usr/include/bits/socket.h:343:24: fatal error: asm/socket.h: No such file
or directory
#include asm/socket.h
^
compilation terminated.
---END SNIPPET FROM BUILD LOG---
% uname -a
Linux foo 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux
% dpkg -S asm/socket.h
linux-headers-3.12-1-common:
/usr/src/linux-headers-3.12-1-common/arch/x86/include/uapi/asm/socket.h
linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/socket.h
linux-headers-3.11-2-common:
/usr/src/linux-headers-3.11-2-common/arch/x86/include/uapi/asm/socket.h
% dpkg -l 'lib*32*dev' | grep ii | awk '{print $2}'
lib32gcc-4.8-dev
lib32readline6-dev
lib32stdc++-4.8-dev
lib32tinfo-dev
libx32gcc-4.8-dev
libx32stdc++-4.8-dev
Any help would be appreciated.
--
Thomas E. Vaughan
Dual-head display with video-intel stopped working on unstable update.
I run unstable and update daily. Last Friday, I happened to log out and log in again---I don't do that every day---and that caused the X server to restart. When it came back up, I noticed that only one of my two monitors had any signal going to it. I'm using the integrated intel video on my motherboard; the VGA output is working, but 'xrandr -q' reports that TMDS-1 is disconnected. Of course, the monitor is really connected, and I see a mirrored display of the console on boot-up before X starts. /var/log/Xorg.0.log shows no EDID data for TMDS-1. That's suspicious right there. Normally---at least according to /var/log/Xorg.1.log---pipe B is on and TMDS-1 is connected to pipe B, but pipe B is now off. I didn't change anything lately, but I have been doing daily updates. I used reportbug to send in a report against xserver-xorg-video-intel, but the list of bugs against the driver is quite long. Does anybody here know about what's going on and whether there's a work-around. I'd rather not go back to the server in testing because it has its own issues with dual-monitor support. -- 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-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: tetex installation bug
MCV == M C Vernon [EMAIL PROTECTED] writes: MCV Thomas, You need to configure tetex-bin and -base at the same MCV time - MCV dpkg --configure tetex-base tetex-bin : $ dpkg --configure tetex-base tetex-bin : Setting up tetex-base (0.9-6) ... : /usr/bin/texconfig: No $TEXMFMAIN; set the environment variable or in texmf.cnf. : dpkg: error processing tetex-base (--configure): : subprocess post-installation script returned error exit status 1 : dpkg: dependency problems prevent configuration of tetex-bin: : tetex-bin depends on tetex-base (= 0.9-1); however: : Package tetex-base is not configured yet. : dpkg: error processing tetex-bin (--configure): : dependency problems - leaving unconfigured : Errors were encountered while processing: : tetex-base : tetex-bin No, that doesn't solve the problem, which has something to do with an environment variable, TEXMFMAIN. Apparently there is a bug somewhere that causes TEXMFMAIN to be unset when it should be set. I don't really know where to look, though. Everything was installed just fine before I tried to update this morning, and so I suspect that others have seen this, too. -- Thomas E. Vaughan[EMAIL PROTECTED] Dept. of Physics Astronomy home: (303) 750-7864 University of Oklahoma, Norman work: (405) 325-3961x36403 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tetex installation bug
GM == Gergely Madarasz [EMAIL PROTECTED] writes: GM On 20 May 1998, Thomas Vaughan wrote: No, that doesn't solve the problem, which has something to do with an environment variable, TEXMFMAIN. Apparently there is a bug somewhere that causes TEXMFMAIN to be unset when it should be set. I don't really know where to look, though. Everything was installed just fine before I tried to update this morning, and so I suspect that others have seen this, too. GM TEXMFMAIN is set in /etc/texmf/texmf.cnf and if you do an GM upgrade somehow the texmf.cnf which is there is from the old GM package which doesnt have TEXMFMAIN, the new is GM /etc/texmf/texmf.cfn.dpkg-new ... i moved it manually, it then GM configured... Thanks. I copied by hand texmf.cnf - texmf.cnf.dpkg-old texmf.cnf.dpkg-new - texmf.cnf in that order and then ran the configure option from dselect's main menu. Here is an excerpt from dselect's output. : running dpkg --pending --configure ... : Setting up tetex-base (0.9-6) ... : config_replace: file './texmf.cnf' not found. : texhash: Updating /usr/lib/texmf/local/ls-R... : texhash: Updating /var/lib/texmf/ls-R... : texhash: Done. : Running initex. This may take some time. ... : Output of initex is in /tmp/tex02208aaa file './texmf.cnf' not found appears here and at least at one other place in the output. In any event, one should not have to copy files by hand during installation. Has anybody reported this as a bug? -- Thomas E. Vaughan[EMAIL PROTECTED] Dept. of Physics Astronomy home: (303) 750-7864 University of Oklahoma, Norman work: (405) 325-3961x36403 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
segmentation fault with glimpseindex
After investigating the segmentation fault that I have observed in the e-mail report from cron.weekly, I ran glimpseindex by hand and observed the following output. : $ glimpseindex -z -H /var/cache/man2html /usr/man/man* /usr/X11R6/man/man* /usr/local/man/man* : : This is glimpseindex version 4.1, 1997. : : Indexing /usr/man/man1 ... : Indexing /usr/man/man2 ... : Indexing /usr/man/man3 ... : Indexing /usr/man/man4 ... : Indexing /usr/man/man5 ... : Indexing /usr/man/man6 ... : Indexing /usr/man/man7 ... : Indexing /usr/man/man8 ... : Indexing /usr/X11R6/man/man1 ... : Indexing /usr/X11R6/man/man3 ... : Indexing /usr/X11R6/man/man4 ... : Indexing /usr/X11R6/man/man5 ... : Indexing /usr/X11R6/man/man6 ... : Indexing /usr/local/man/man1 ... : Indexing /usr/local/man/man2 ... : Indexing /usr/local/man/man3 ... : Indexing /usr/local/man/man4 ... : Indexing /usr/local/man/man5 ... : Indexing /usr/local/man/man6 ... : Indexing /usr/local/man/man7 ... : Indexing /usr/local/man/man8 ... : Indexing /usr/local/man/manl ... : Indexing /usr/local/man/mann ... : Indexing /usr/local/man/manp ... : : Size of files being indexed = 10536941 B, Total #of files = 5107 : Segmentation fault Is there an easy way for me to fix this, or is it a bug that needs to be addressed? -- Thomas E. Vaughan[EMAIL PROTECTED] Dept. of Physics Astronomy home: (303) 750-7864 University of Oklahoma, Norman work: (405) 325-3961x36403 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tetex installation bug
I just this morning updated my hamm system with dselect but found the following problem: : Setting up tetex-base (0.9-6) ... : Installing new version of config file /etc/texmf/language.dat ... : /usr/bin/texconfig: No $TEXMFMAIN; set the environment variable or in texmf.cnf. : dpkg: error processing tetex-base (--install): : subprocess post-installation script returned error exit status 1 : dpkg: dependency problems prevent configuration of tetex-nonfree: : tetex-nonfree depends on tetex-base (= 0.9-1); however: : Package tetex-base is not configured yet. : dpkg: error processing tetex-nonfree (--install): : dependency problems - leaving unconfigured : Setting up lapack-dev (2.0.1-2.1) ... : Setting up ncurses3.4-dev (1.9.9g-8.3) ... : Setting up ncurses-term (1.9.9g-8.3) ... : : Setting up ncurses-bin (1.9.9g-8.3) ... : dpkg: dependency problems prevent configuration of tetex-extra: : tetex-extra depends on tetex-base (= 0.9-1) etc. Has anybody else seen this? -- Thomas E. Vaughan[EMAIL PROTECTED] Dept. of Physics Astronomy home: (303) 750-7864 University of Oklahoma, Norman work: (405) 325-3961x36403 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
