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 2>&1 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 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/30
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
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 #include #include #include GLboolean checkglx(Display *dpy, int scr, char *extension) { static char *glxexts = NULL; char *start, *next; int extlen = strlen(ext
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- SERR- 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 -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 Dec 10 14:33 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 54 Dec 10 14:33 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 Dec 10 14:33 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu
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#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#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]