Bug#819383: libasound2-plugin-equal: Cannot install 32-bit and 64-bit plugin simultaneously
Package: libasound2-plugin-equal Version: 0.6-6 Severity: normal Dear Maintainer, I had installed 64-bit ALSA equalizer plugin and configured ALSA to use it as the default sound output. However, 32-bit programs (e.g. wine) failed to load it and complained about missing 32-bit plugin. An attempt to install 32-bit and 64-bit plugin at once complains that 32-bit one needs 32-bit caps and 64-bit one needs 64-bit caps. The following is the apt-get install output: 0_ilan@nbh1 /tmp%sudo apt-get install libasound2-plugin-equal:amd64 libasound2-plugin-equal:i386 Reading package lists... Done Building dependency tree Reading state information... Done libasound2-plugin-equal is already the newest version. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libasound2-plugin-equal:i386 : Depends: caps:i386 (>= 0.9.11) but it is not going to be installed E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libasound2-plugin-equal depends on: ii caps 0.9.23-1 ii libasound2 1.0.28-1 ii libc6 2.19-18+deb8u2 ii multiarch-support 2.19-18+deb8u1 libasound2-plugin-equal recommends no packages. libasound2-plugin-equal suggests no packages. -- no debconf information
Bug#788106: kpsewhich behavior changed?
On Tue, Jun 09, 2015 at 10:40:48PM +0900, Osamu Aoki wrote: Hi, Was there major change in kpathsearch for jessie? That is the question. If that is the case, I need to fix this in stable=jessie. Nobert, can you elaborate, if you know. No, kpathsearch is pretty stable. This is just my host config issue. While I think that present behavior is a bug, and that it broke things in a pretty legal configuration, and that fix will not break anything -- I don't think that it is reasonable to push it into stable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788106: debiandoc-sgml: debiandoc2pdf does not set -progname to kpsewhich
On Tue, Jun 09, 2015 at 01:34:02AM +0900, Osamu Aoki wrote: Hi, On Mon, Jun 08, 2015 at 07:09:43PM +0300, Ilya Anfimov wrote: Package: debiandoc-sgml Version: 1.2.29-1 Severity: normal Dear Maintainer, I have some specifics in kpse path search library configuration, and latex packages do not appear there by default. Whould you be so kind to add -progname pdflatex to kpsewhich calls in debiandoc2pdf, so to check exact availability of that packages for pdflatex? $ dpkg -S kpsewhich texlive-binaries: /usr/share/man/man1/kpsewhich.1.gz texlive-binaries: /usr/bin/kpsewhich $ zgrep kpsewhich `dpkg -L debiandoc-sgml` /usr/bin/debiandoc2latexpdf:if ! kpsewhich \ /usr/bin/debiandoc2latexpdf:if ! kpsewhich \ /usr/bin/debiandoc2latexpdf:if ! kpsewhich \ /usr/bin/debiandoc2latexps:if ! kpsewhich \ /usr/bin/debiandoc2latexps:if ! kpsewhich \ /usr/bin/debiandoc2latexps:if ! kpsewhich \ /usr/bin/debiandoc2latexdvi:if ! kpsewhich \ /usr/bin/debiandoc2latexdvi:if ! kpsewhich \ /usr/bin/debiandoc2latexdvi:if ! kpsewhich \ /usr/bin/debiandoc2ps:if ! kpsewhich \ /usr/bin/debiandoc2ps:if ! kpsewhich \ /usr/bin/debiandoc2ps:if ! kpsewhich \ /usr/bin/debiandoc2dvi:if ! kpsewhich \ /usr/bin/debiandoc2dvi:if ! kpsewhich \ /usr/bin/debiandoc2dvi:if ! kpsewhich \ /usr/bin/debiandoc2pdf:if ! kpsewhich \ /usr/bin/debiandoc2pdf:if ! kpsewhich \ /usr/bin/debiandoc2pdf:if ! kpsewhich \ I do not understand what you are after. Please assume me as total newbie for latex. What is add -progname pdflatex? I have no idea what you are asking. Please report woth log of what you did and where in the installed files needs to be changed. (Patch to the source is even better.) Oh, sorry. The patch is attached. kpathsearch library, used by texlive programs to find it's files in local filesystem, asks for program name for search con- fig. Usually most TeX and even LaTeX style files and top-level addons could be found without specifing program name, to simplify searching in distinct tex flavours -- tex, latex, luatex, pdfla- tex, ... However, this is changed on my system, and debiandoc2... scripts reports uninstalled latex packages despite the fact that packages are installed latex/pdflatex runs just fine from debiandoc. Attached patch adds -progname to respective calls to kpsewich. Index: debiandoc-sgml-1.2.29/tools/bin/template === --- debiandoc-sgml-1.2.29.orig/tools/bin/template +++ debiandoc-sgml-1.2.29/tools/bin/template @@ -155,10 +155,17 @@ then fi @@@end-latexpdf-active@@@ -@@@start-latexdvi-latexps-latexpdf-active@@@ +@@@start-latexdvi-latexps-active@@@ ## -- ## check for presence of used latex styles -if ! kpsewhich \ +if ! kpsewhich -progname latex \ +@@@end-latexdvi-latexps-active@@@ +@@@start-latexpdf-active@@@ +## -- +## check for presence of used pdflatex styles +if ! kpsewhich -progname pdflatex \ +@@@end-latexpdf-active@@@ +@@@start-latexdvi-latexps-latexpdf-active@@@ fancyhdr.sty \ helvet.sty \ hyperref.sty \ @@ -174,10 +181,17 @@ then fi @@@end-latexdvi-latexps-latexpdf-active@@@ -@@@start-latexdvi-latexps-latexpdf-active@@@ +@@@start-latexdvi-latexps-active@@@ ## -- ## check for presence of used latex styles -if ! kpsewhich \ +if ! kpsewhich -progname latex \ +@@@end-latexdvi-latexps-active@@@ +@@@start-latexpdf-active@@@ +## -- +## check for presence of used pdflatex styles +if ! kpsewhich -progname pdflatex \ +@@@end-latexpdf-active@@@ +@@@start-latexdvi-latexps-latexpdf-active@@@ footmisc.sty \ paralist.sty \ vmargin.sty \ @@ -189,10 +203,17 @@ then fi @@@end-latexdvi-latexps-latexpdf-active@@@ -@@@start-latexdvi-latexps-latexpdf-active@@@ +@@@start-latexdvi-latexps-active@@@ ## -- ## check for presence of used latex styles -if ! kpsewhich \ +if ! kpsewhich -progname latex \ +@@@end-latexdvi-latexps-active@@@ +@@@start-latexpdf-active@@@ +## -- +## check for presence of used pdflatex styles +if ! kpsewhich -progname pdflatex \ +@@@end-latexpdf-active@@@ +@@@start-latexdvi-latexps-latexpdf-active@@@ wasysym.sty \ /dev/null 21 then
Bug#788106: debiandoc-sgml: debiandoc2pdf does not set -progname to kpsewhich
Package: debiandoc-sgml Version: 1.2.29-1 Severity: normal Dear Maintainer, I have some specifics in kpse path search library configuration, and latex packages do not appear there by default. Whould you be so kind to add -progname pdflatex to kpsewhich calls in debiandoc2pdf, so to check exact availability of that packages for pdflatex? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.0 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debiandoc-sgml depends on: ii libhtml-parser-perl 3.71-1+b3 ii libroman-perl1.23-1 ii libtext-format-perl 0.59-1 ii perl 5.20.2-3 ii sgml-base1.26+nmu4 ii sgml-data2.0.10 ii sgmlspl 1.03ii-33 ii sp 1.3.4-1.2.1-47.3 Versions of packages debiandoc-sgml recommends: ii ghostscript 9.06~dfsg-2 ii texinfo 5.2.0.dfsg.1-6 ii texlive 2014.20141024-2 ii texlive-latex-extra 2014.20141024-1 Versions of packages debiandoc-sgml suggests: pn debiandoc-sgml-doc none ii latex-cjk-all 4.8.3+git20140831-1 ii texlive-lang-all2014.20141024-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections
On Fri, Dec 19, 2014 at 12:33:34PM +0100, Andreas Beckmann wrote: [skipped] connecting to the nvidia-driven X-server from machine with mesa or ATI libGL drivers. Can you run the X-server machine with the supported configuration from update-alternatives --set glx /usr/lib/nvidia also /usr/lib/xorg/modules/extensions/libglx.so, libnvglx.so are manual symlinks, get rid of them, too reinstall xserver-xorg-core to get back the xorg libglx.so and maybe try a minimal xorg.conf as describd in the README.Debian OK, tested on fresh Debian/testing install from DVD After fresh install of base system: 2) apt-get install nvidia-legacy-304xx-driver (rebooted, as recommended due to nouveau driver) root@glt2:~# apt-cache policy nvidia-legacy-304xx-driver nvidia-legacy-304xx-driver: Installed: 304.123-4 Candidate: 304.123-4 Version table: *** 304.123-4 0 500 http://cdn.debian.net/debian/ jessie/non-free amd64 Packages 100 /var/lib/dpkg/status apt-get install xinit twm Created minimal working xorg.conf: Section Device Identifier My GPU Driver nvidia Option NoPowerConnectorCheck True EndSection (yes, I know, that I've forgotten power connector. All I needed from this fanless videoadapter works fine without it, even games, and it hardly will break support of setting of buffer swap con- trol frquency) ssh -X to wheezy virtual machine with glx alternative set to libgl1-mesa: root@trzbase:~# /tmp/swabsgi X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 156 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 root@trzbase:~# echo $? 1 root@trzbase:~# ssh -X to wheezy host with fglrx: root@trzbase:~# /tmp/swabsgi X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 156 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 34 Current serial number in output stream: 35 root@trzbase:~# echo $? 1 ssh -X to wheezy host with nvidia-glx, 304.117 (it works mostly as expected): root@trzbase:~# /tmp/swabsgi ERROR: could not insert 'nvidia': No such device NVIDIA: failed to load the NVIDIA kernel module. root@trzbase:~# echo $? 0 ssh -X to wheezy host with nvidia-glx-legacy71xx (works good, the same as 304.117): root@trzbase:~# /tmp/swabsgi ERROR: could not insert 'nvidia': No such device NVIDIA: failed to load the NVIDIA kernel module. root@trzbase:~# echo $? 0 local test with glx set to nvidia, which is nvidia-legacy-304xx driver -- all is fine, no error messages, in both indirect (__GL_FORCE_INDIRECT=1 ) and direct modes. Tryed installation of 304.125 drivers: sudo dpkg -i libgl1-nvidia-legacy-304xx-glx_304.125-1_amd64.deb \ libgl1-nvidia-legacy-304xx-glx_304.125-1_i386.deb \ libgl1-nvidia-legacy-304xx-glx-i386_304.125-1_i386.deb \ nvidia-legacy-304xx-alternative_304.125-1_amd64.deb \ nvidia-legacy-304xx-alternative_304.125-1_i386.deb \ nvidia-legacy-304xx-driver_304.125-1_amd64.deb \ xserver-xorg-video-nvidia-legacy-304xx_304.125-1_amd64.deb \ nvidia-legacy-304xx-kernel-dkms_304.125-1_amd64.deb The nvidia-legacy-304xx-alternative:i386 caused some dependency error, just removed it immediately. All attempt to use glx fail, in any app, even with nvidia libs: root@glt2:~# __GL_FORCE_INDIRECT=1 glxinfo name of display: :0.0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 156 (GLX) Minor opcode of failed request: 24 (X_GLXCreateNewContext) Value in failed request: 0x0 Serial number of failed request: 33 Current serial number in output stream: 34 root@glt2:~# (it is working nvidia libs with the same version, as direct rendering works fine) I'm not sure, wheter should I post new bug about this or it is OK to continue with that here. However, it is definitely a different bug. Taken tcpdump with direct and indirect glxinfo at 304.125, nvidia glx (all indirect ones -- failed on X_GLXCreateNewContext), and glxinfo and swabsgi at 304.123 -- with nvidia glx -- glxinfo worked, swabsgi worked in both direct and indirect modes, swabsgi failed with mesa (indirect) glx. Example of Mesa glx drivers output: root@glt2:~# ./swabsgi libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 156 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 48 Current serial number in output stream: 49 I'm not sure I should fill debian bug tracker with this dumps, so putting it separately: 304.125 X Server driver: glxinfo, working, glx 304.125 direct mode: http://tzirechnoy.com/dl/dumps/304.125-glx.dump
Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections
On Wed, Dec 17, 2014 at 01:03:46AM +0100, Andreas Beckmann wrote:
On 2014-12-10 16:32, Ilya Anfimov wrote:
Dear Maintainer, I'm trying to run OpenGL acceleration in indi-
rect GLX mode on an old NVidia graphics card. The OpenGL library
is set to mesa, as it should have sufficient GLX implementation,
it works fine with other X-servers (cygwin/intel) and it will
definitely not support direct rendering to server with propri-
etary nvidia driver.
I'm not sure that is a supported setup ...
You have a lot of nvidia related cruft on that historically grown machine:
Thanks for your interest in this issue.
After investigation, it looks partially true: nvidia_drv.so
symlink in /usr/lib/xorg/modules/drivers is made by hand, as
update-alternatives --set glx /usr/lib/mesa-diverted
removes this symlink.
Hoever, while README states that this configuration is official-
ly unsupported (which is sad), the bug also could be triggered by
connecting to the nvidia-driven X-server from machine with mesa
or ATI libGL drivers.
* some 340.xx driver packages are installed, but that does not support
your card, remove them
OK, I'll try that on fresh debian this weekend (when I could
boot it from usb flash for experiments).
However, I think that nvidia-alternative is exactly for keeping
both versions on one machine.
* lots of files from older .run driver installations have been left on
your box, move them aside or delete them:
Thanks, I removed this old stuff.
This didn't change anything (started another X server for test-
ing).
btw, I've written small C example demonstrating problem and at-
tached it.
[skipped]
you explicitly disabled the nvidia module:
/etc/modprobe.d/nvidia-kernel-common.conf
alias char-major-195* nvidia
options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44
NVreg_DeviceFileMode=0660
# To enable FastWrites and Sidebus addressing, uncomment these lines
# options nvidia NVreg_EnableAGPSBA=1
# options nvidia NVreg_EnableAGPFW=1
# see #580894
#blacklist nouveau
options nouveau modeset=1
blacklist nvidia
^^ /etc/modprobe.d/nvidia-kernel-common.conf ^^
nevertheless, nvidia is loaded:
0_ilan@azor /tmp%lsmod |grep nvidia
nvidia 11285975 56
i2c_core 15803 13
i2c_piix4,nvidia,videodev,v4l2_common,tveeprom,saa7134,tuner,tda8290,tda9887,tea5767,tuner_simple,i2c_nforce2,eeprom
0_ilan@azor /tmp%lsmod |grep nouveau
1_ilan@azor /tmp%
I don't know why -- is it because the nvidia xorg driver loads
it via insmod, skipping modprobe rules, or because nvidia is an
alias of nvidia-legacy-304xx:
0_ilan@azor /etc/modprobe.d%cat nvidia.conf
alias nvidia nvidia-legacy-304xx
remove nvidia-legacy-304xx rmmod nvidia
0_ilan@azor /etc/modprobe.d%
Unfortunately the bug script did not collect information about the
nvidia things in /usr/lib/xorg/modules (this will be fixed in
304.125-1), I would expect that there are even more files from old versions.
There really was libnvidia-wfb.so* . Removing it and starting X
server with buggy glx driver doesn't change anything.
Also, I had attached ls -l on all those directories, just in
case you'll want to see it.
In the end you probably loaded a mix of incompatible versions resulting
in your failures.
Server version is definitely 304.123 -- nvidia driver and nvidia
glx module are linked to specific libraries, and they scream when
they are of diffirent versions or when kernel module is different
version. Attached mmap of X-server, proving that.
Client is Mesa (without any dri installed), it should not take
any touch of nvidia libraries.
Also, I've taken some experiments, and found that nvidia
libGL.so.1 works fine. It works in both direct and indirect mode.
It also works fine with -340 version of client library (only
indirect mode, of course).
Wireshark view of indirect mode traffic shows, that in nvidia
glx library glXSwapIntervalSGI is made by some NV-GLX extension
requests, undecoded as there is no NV-GLX decode support in wire-
shark. I don't know simple ways to disable usage of NV-GLX, so I
don't know what this client library will do when it will not find
NV-GLX extension on server.
ATI's libgl1-fglrx-glx libGL.so.1 library fails, nearly the
same way as MESA one.
Andreas
#include stdio.h
#include string.h
#include GL/glx.h
#include GL/gl.h
GLboolean checkglx(Display *dpy, int scr, char *extension) {
static char *glxexts = NULL;
char *start, *next;
int extlen = strlen(extension);
if (!glxexts) {
glxexts = (char *)glXQueryExtensionsString(dpy, scr);
};
if (glxexts) {
for (next = start = glxexts; next; start=next) {
if ((next = strstr(start, extension))) {
if ( ((start == glxexts) ||
(*(start-1) == ' '))
((*(next + extlen) == '\0
Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections
On Fri, Dec 19, 2014 at 12:33:34PM +0100, Andreas Beckmann wrote: [skipped] I'm terribly sorry, I found that in my first letter the method for reproducing the bug is completely incorrect. I found the bug when working with tcl3d, installed in /usr/local/ When I've found that debian doesn't have tcl3d, I've tried to use togl, and I just mistaken it's usage. And it cannot be reproduced using togl alone. The real step to reproduce is to compile and run swabsgi.c from my second letter. The erroneous output would be: 0_ilan@azor /tmp%./swabsgi libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 48 Current serial number in output stream: 49 1_ilan@azor /tmp% Hoever, while README states that this configuration is official- ly unsupported (which is sad), the bug also could be triggered by connecting to the nvidia-driven X-server from machine with mesa or ATI libGL drivers. Can you run the X-server machine with the supported configuration from update-alternatives --set glx /usr/lib/nvidia I'll do that tomorrow, but this will not trigger bug locally -- as in all supported configurations, server driver is always the same as client libGL. Well, not exactly impossible, I can dpkg-reconfigure glx after launching server, but it is not a polite way too. However, I'll find remote connection with fresh virtual debian to confirm the bug. [also removed that old and unpackaged files, that you point me in this message] also /usr/lib/xorg/modules/extensions/libglx.so, libnvglx.so are manual symlinks, get rid of them, too reinstall xserver-xorg-core to get back the xorg libglx.so thanks, reinstalled this also. [skipped] Server version is definitely 304.123 -- nvidia driver and nvidia glx module are linked to specific libraries, and they scream when they are of diffirent versions or when kernel module is different version. Attached mmap of X-server, proving that. please update to 304.125 Updated, it looks like glx interoperability is broken completely (BadValue is in X_GLXCreateContext now with Mesa libGL): 0_ilan@azor /tmp%./swabsgi libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 37 Current serial number in output stream: 38 Moreover, with 304.125 driver and Mesa libGL -- glxinfo prints the same error. However, didn't rebooted yet, just stopped X-server and replaced nvidia kernel module. Client is Mesa (without any dri installed), it should not take any touch of nvidia libraries. So X is tunneled (via ssh)? This increases the fun ... :-) Exactly mine is not -- I am just using mesa client libraries to be more predictable and traceable, and surely deny direct render- ing. However, there seems to be misinterpretation of GLX protocol in nvidia driver, and remote setup will fail even in supported con- figuration. Are things working *locally*? Also, I've taken some experiments, and found that nvidia libGL.so.1 works fine. It works in both direct and indirect mode. It also works fine with -340 version of client library (only indirect mode, of course). Wireshark view of indirect mode traffic shows, that in nvidia glx library glXSwapIntervalSGI is made by some NV-GLX extension requests, undecoded as there is no NV-GLX decode support in wire- shark. I don't know simple ways to disable usage of NV-GLX, so I don't know what this client library will do when it will not find NV-GLX extension on server. ATI's libgl1-fglrx-glx libGL.so.1 library fails, nearly the same way as MESA one. Need to think more about this ... Andreas PS: I'll be mostly offline over the holidays -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772740: xserver-xorg-video-nvidia-legacy-304xx: No glXSwapIntervalSGI despite reported GLX_SGI_swap_control in socket-based connections
Package: xserver-xorg-video-nvidia-legacy-304xx
Version: 304.123-4
Severity: normal
Dear Maintainer, I'm trying to run OpenGL acceleration in indi-
rect GLX mode on an old NVidia graphics card. The OpenGL library
is set to mesa, as it should have sufficient GLX implementation,
it works fine with other X-servers (cygwin/intel) and it will
definitely not support direct rendering to server with propri-
etary nvidia driver.
Some programs, though, failed with message
0_ilan@azor /tmp%wish8.5 ./gl.tcl
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 53
Current serial number in output stream: 54
1_ilan@azor /tmp%
(example script is
#!/usr/bin/tclsh
package require Togl
proc none {} {}
set toglwin [togl .gl -displayproc none]
pack .gl
)
libGL load driver errors seems unrelevant to this issue, and
wireshark shows, that this is the glx vendorprivate request with
vendor ID 65536 -- i.e., in fact it is glXSwapIntervalSGI
from SGI_swap_control extension. It is called just after cre-
ateing context 1, with that context 1 as request's glx context
and with 32-bit 1 value as parameter. Server does
reports GLX_SGI_swap_control, so everything should work fine.
Nevertheless, server reports UnsupportedPrivateRequest.
Indeed, changingeveryGLX_SGI_swap_controlinthe
/usr/lib/nvidia/legacy-304xx/libglx.so.304.123 binary to
GLX_SGI_twap_control and restarting server fixes the issue
(client doesn't try to use GLX_SGI_swap_control and everything
works fine).
Also, this is the only swap_control common to both client and
server. I don't know, whether other server reported swap_control
(GLX_EXT_swap_control) will work.
-- Package-specific info:
uname -a:
Linux azor 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC 2014 x86_64 GNU/Linux
/proc/version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-48squeeze6) (j...@debian.org) (gcc
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue May 13 16:34:35 UTC 2014
/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.123 Wed Jul 2 10:59:22
PDT 2014
GCC version: gcc version 4.3.6 (Debian 4.3.6-1)
lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G71 [GeForce 7900
GS] [10de:0292] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fa00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at fb00 (64-bit, non-prefetchable) [size=16M]
Region 5: I/O ports at ef00 [size=128]
[virtual] Expansion ROM at fc00 [disabled] [size=128K]
Capabilities: access denied
Kernel driver in use: nvidia
Kernel modules: nvidiafb, nouveau, nvidia
dmesg:
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.442764] vgaarb: device added:
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.442823] vgaarb: loaded
[0.811547] Linux agpgart interface v0.103
[7.227988] nvidia: module license 'NVIDIA' taints kernel.
[7.510395] nvidia :01:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18
[7.510459] nvidia :01:00.0: setting latency timer to 64
[7.510465] vgaarb: device changed decodes:
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[7.510804] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 304.123 Wed Jul
2 10:59:22 PDT 2014
OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 22 Dec 10 14:33 /etc/alternatives/glx -
/usr/lib/mesa-diverted
lrwxrwxrwx 1 root root 51 Dec 10 14:33
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 48 Dec 9 2013
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 Dec 9 2013
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 Dec 10 14:33
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 48 Dec 10 14:33
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 Dec 10 14:33
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -
Bug#521538: libgv-tcl: Tcldot libraries placed out of search path, Tkspline missed from pkgIndex.tcl
Package: libgv-tcl Version: 2.20.2-3 Severity: important Tags: patch 1) Libraries are placed under /usr/lib/tcltk/graphviz/tcl/. While /usr/lib/tcltk in tcl libs search path, and it search one directory down of it's search path for libraries -- it misses Tcldot and other TCL package from this .deb without some manual intervention. Small change to debian/libgv-tcl.install fixes this problem 2) The tkspline library, while correctly build, does not appear in pkgIndex.tcl file -- and there fore does not load in tcl by package require Tkspline Setting proper TK_PKGINDEX in configure.ac depends on variable $HAVE_TK, which never appears in any other part of configure. Changing it to $use_tk = Yes and re-running autoconf fixes the problem -- System Information: Debian Release: 5.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.koi8-r, LC_CTYPE=ru_RU.koi8-r (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages libgv-tcl depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra ii libexpat1 2.0.1-4 XML parsing C library - runtime li ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc11:4.3.3-3 GCC support library ii libgd2-xpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2 ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgraphviz4 2.20.2-3 rich set of graph drawing tools ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libltdl3 1.5.26-4 A system independent dlopen wrappe ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio ii libpng12-0 1.2.27-2 PNG library - runtime ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxpm41:3.5.7-1 X11 pixmap library ii tk8.4 8.4.19-2 Tk toolkit for Tcl and X11, v8.4 - ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime libgv-tcl recommends no packages. libgv-tcl suggests no packages. -- no debconf information --- graphviz-2.20.2/configure.ac2008-06-26 03:17:56.0 +0400 +++ ./graphviz-2.20.2.patched/configure.ac 2009-03-27 20:15:26.641887077 +0300 @@ -2527,7 +2527,7 @@ if test x$SWIG != x; then TCL_PKGINDEX_SWIG=gv/pkgIndex.tcl fi -if test $HAVE_TK = 1; then +if test $use_tk = Yes; then TK_PKGINDEX=tkspline/pkgIndex.tcl fi fi --- graphviz-2.20.2/debian/libgv-tcl.install2009-03-28 13:18:41.0 +0300 +++ ./graphviz-2.20.2.patched/debian/libgv-tcl.install 2009-03-27 19:36:25.504964755 +0300 @@ -1,4 +1,4 @@ -usr/lib/graphviz/tcl usr/lib/tcltk/graphviz +usr/lib/graphviz/tcl/* usr/lib/tcltk/graphviz usr/share/man/man3/gv_tcl.3 usr/share/man/man3/gdtclft.3 usr/share/man/man3/tkspline.3
Bug#521539: libgv-tcl: Tcldot render command prints canvas commands to stdout instead of returning
Package: libgv-tcl
Version: 2.20.2-3
Severity: important
Tags: patch
Well, the problem from subject. It could be checked
by attempting to run doted from graphviz examples on
any example graph. Nothing will appear on screen,
but canvas code is printed to console.
Indeed, tcldot calls tk renderer, assuming that
it will be tkgen.c code. That code have all the needed
to return it's canvas paint strings to TCL. However,
now tk renderer is also available from the common plugins of
libgv. By default it just prints it's results to stdout.
The simplest method of fixing it is to change name
of internal tcldot renderer from tk to tkgen.
Also, changed renderer type from API_render to API_device --
all other codegen_t renderers are API_device, and without
it attempting to call gvjobs_output_langname would fail.
Attached patch implements this method.
There could be another way of fixing -- to add hook to
gvc device to write all rendering results via Tcl_AppendResult
in tcldot.c. This would allow to use standard tk
rendering backend. However, this is less simple
and, as I saw in tk plugin code -- it appears to have
less features then tkgen.
-- System Information:
Debian Release: 5.0
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.koi8-r, LC_CTYPE=ru_RU.koi8-r (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgv-tcl depends on:
ii libc6 2.7-18GNU C Library: Shared libraries
ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra
ii libexpat1 2.0.1-4 XML parsing C library - runtime li
ii libfontconfig1 2.6.0-3 generic font configuration library
ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib
ii libgcc11:4.3.3-3 GCC support library
ii libgd2-xpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2
ii libglib2.0-0 2.16.6-1 The GLib library of C routines
ii libgraphviz4 2.20.2-3 rich set of graph drawing tools
ii libjpeg62 6b-14 The Independent JPEG Group's JPEG
ii libltdl3 1.5.26-4 A system independent dlopen wrappe
ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio
ii libpng12-0 1.2.27-2 PNG library - runtime
ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3
ii libx11-6 2:1.1.5-2 X11 client-side library
ii libxpm41:3.5.7-1 X11 pixmap library
ii tk8.4 8.4.19-2 Tk toolkit for Tcl and X11, v8.4 -
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
libgv-tcl recommends no packages.
libgv-tcl suggests no packages.
-- no debconf information
--- graphviz-2.20.2/tclpkg/tcldot/tcldot.c 2008-04-29 21:31:05.0 +0400
+++ graphviz-2.20.2.patched/tclpkg/tcldot/tcldot.c 2009-03-28 13:26:00.350041677 +0300
@@ -53,7 +53,7 @@
#ifdef WITH_CODEGENS
extern codegen_t TK_CodeGen;
-static codegen_info_t cg[] = { {TK_CodeGen, tk, TK},
+static codegen_info_t cg[] = { {TK_CodeGen, tkgen, TK},
{NULL, NULL, 0}, };
#endif
@@ -1084,9 +1084,9 @@
}
tkgendata.interp = interp;
-rc = gvjobs_output_langname(gvc, tk);
+rc = gvjobs_output_langname(gvc, tkgen);
if (rc == NO_SUPPORT) {
- Tcl_AppendResult(interp, Format: \tk\ not recognized.\n,
+ Tcl_AppendResult(interp, Format: \tkgen\ not recognized.\n,
(char *) 0);
return TCL_ERROR;
}
@@ -1672,9 +1672,10 @@
gvconfig(gvc, FALSE);
#ifdef WITH_CODEGENS
/* additional codegens */
-for (p = cg; p-name; ++p)
-gvplugin_install(gvc, API_render, p-name, 0, cg, NULL,
+for (p = cg; p-name; ++p) {
+gvplugin_install(gvc, API_device, p-name, 0, cg, NULL,
(gvplugin_installed_t *) p);
+};
#endif
#ifndef TCLOBJ
Bug#281201: wget prints it's progress even when background
My suggestion is to stop printing verbose progress messages when the job is resumed in background. It could be checked by (successful) getpgrp() not equal to (successful) tcgetprp(1) in SIGCONT signal handler. And something like this is used in some console applications, for example, in lftp. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375976: flow-tools: There is two-strings patch, that fixes the problem.
Package: flow-tools
Version: 1:0.67-8
Followup-For: Bug #375976
diff -ru flow-tools-0.68.orig/lib/ftstat.c flow-tools-0.68/lib/ftstat.c
--- flow-tools-0.68.orig/lib/ftstat.c 2005-05-10 19:48:12.0 +0400
+++ flow-tools-0.68/lib/ftstat.c2006-11-14 14:37:02.0 +0300
@@ -11673,10 +11673,10 @@
ftch_recprefix_tag, ftch_recprefix_tagp);
FT_RECGET_DSTADDR(cur,rec,*fo);
- FT_RECGET_DST_TAG(cur,rec,*fo);
+ FT_RECGET_SRC_TAG(cur,rec,*fo);
ftch_recprefix_tag.prefix = cur.dstaddr;
- ftch_recprefix_tag.tag = cur.dst_tag;
+ ftch_recprefix_tag.tag = cur.src_tag;
/* only use mask if option set */
if (rpt-options (FT_STAT_OPT_DST_PREFIX_MASK|FT_STAT_OPT_DST_PREFIX_LEN))
{
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Versions of packages flow-tools depends on:
ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
ii libmysqlclient12 4.0.24-10sarge2mysql database client library
ii libpq37.4.7-6sarge2 PostgreSQL C client library
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii zlib1g1:1.2.2-4.sarge.2 compression library - runtime
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375976: flow-tools: ip-destination-address/source-tag report does ip-destination-address/destination-tag instead
Package: flow-tools Version: 1:0.67-8 Severity: normal ip-destination-address/source-tag report doesn't work -- it do that same as ip-destination-address/destination-tag. This have tought me in real life, and is clearly visible in sources: ftstat_rpt_72_accum from lib/ftstat.c, which is mentioned in ip-destination-address/source-tag definition, uses FT_RECGET_DSTADDR(cur,rec,*fo); FT_RECGET_DST_TAG(cur,rec,*fo); for calculations. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages flow-tools depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libmysqlclient12 4.0.24-10sarge1 mysql database client library ii libpq3 7.4.7-6sarge1 PostgreSQL C client library ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323632: xspecs: missing XIE and XKB docs
Package: xspecs
Version: 4.3.0.dfsg.1-14
Severity: normal
The xfree86 sources contains specifications on XKB (X Keyboard
extension, in xc/{hardcopy,specs}/XKB) and on XIE (X Image extension,
in xc/{hardcopy,specs}/XIE. But it appear that there is no such
documentation packaged in Debian XFree86 package.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.7-1-386
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
