Bug#1076005: libdrm build-dep should be >=2.4.116
Source: xwayland Version: 24.1.0-1 Severity: normal Tags: patch xwayland Build-Depends on libdrm-dev (>= 2.4.89), but actual build-time check verifies libdrm is at least of version 2.4.116 and fails if it is not: env[PKG_CONFIG_PATH]: Called `/usr/bin/pkg-config --libs libdrm` -> 0 stdout: -ldrm --- Dependency libdrm found: NO found 2.4.114 but need: '>= 2.4.116' Dependency lookup for libdrm with method 'pkgconfig' failed: Invalid version, need 'libdrm' ['>= 2.4.116'] found '2.4.114'. (this was an attempt to build xwayland on bookworm). Please specify actual minimum required version of libdrm-dev. (Using Tags: patch without actual patch, since the change is trivial.) Thanks, /mjt
Bug#799379: qxl: wrong wording in the package descriptions
Source: xserver-xorg-video-qxl Version: 0.1.4-3 Severity: minor Current wording of the package description is: Xspice is an X server and Spice server in one. It consists of a wrapper script for executing Xorg with the right parameters and environment variables, a module names spiceqxl_drv.so implementing three drivers: a video mostly code identical to the guest qxl X driver, and keyboard and mouse reading from the spice inputs channel. A "video mostly-code" ? Apparently "mostly" and "code" should be exchanged with each other :) Thanks, /mjt
Bug#668537: please provide xspice package
Source: xserver-xorg-video-qxl Version: 0.0.17-1 Severity: wishlist Since 0.0.16 version, xspice bits has been merged into x86-video-qxl source tarball, built with --enable-xspice configure flag. Please provide either a separate package, say, xserver-xorg-xspice, or enable xspice in the same xserver-xorg-video-qxl package. Note: README.xpsice in x86-video-qxl-0.0.17.tar.gz still refers to external xspice git repository, -- this is an error just in the README.xspice file. Actual build is done just by adding --enable-xspice configure flag, with appropriate dependencies (libspice-server). Thank you! -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120412153937.611.6236.reportbug@gandalf.local
Bug#615153: exec: 58: /usr: Permission denied
13.04.2011 11:55, Jonathan Nieder wrote: [] So, when I restart my machine and try to start my X with the command startx, the system returns the error: xinit: connection to X server lost and after said Wait for X server to shut down and stayed with prompt flashing again. but the strace you sent does not show that message[2]. Instead it shows X: user not authorized to run the X server, aborting due to open(/etc/X11/Xwrapper.config, O_RDONLY) = -1 EACCES (Permission denied) What does ls -l /usr/bin/X /etc/X11/Xwrapper.config tell? For reference, on my system, it gives -rw--- 1 root root 601 Jan 31 08:31 /etc/X11/Xwrapper.config -rwsr-sr-x 1 root root 9024 Apr 2 10:23 /usr/bin/X Notice in particular the setuid (s) bits on X. Is it the same on yours? Do you use any unusual filesystem or kernel feature (selinux, apparmor, etc) that might cause that not to work? When you run something under strace, setuid/setgid bits are ignored by the kernel, the processes will run as user who started them. This is significant difference in environment with and without strace. JFYI. /mjt -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da69fd6.4010...@msgid.tls.msk.ru
Bug#615153: exec: 58: /usr: Permission denied
14.04.2011 11:38, Jonathan Nieder wrote: Michael Tokarev wrote: When you run something under strace, setuid/setgid bits are ignored by the kernel, the processes will run as user who started them. This is significant difference in environment with and without strace. JFYI. Thanks, I should have remembered (allowing ptrace to control setuid programs would be a huge security hole). Sorry for the thinko. invisiblemanguard, could you give an exact set of commands and the exact output produced, when I think it's not necessary. See #618023: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618023 The issue we see here is due to bug in dash which is now fixed. This bug, if my theory is correct, should become a duplicate of #618023. Thanks. /mjt -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da6ae4a.7050...@msgid.tls.msk.ru
Bug#581338: x11-common sets wrong permissions for Xwrapper.config
Package: x11-common Version: 1:7.3+20 Severity: minor Tags: patch In x11-common.postinst the /etc/X11/Xwrapper.config gets created using tmpfile ($NEW_XWRAPPER_CONFIG). By default, tmpfile creates temp file with mode 0600. With that mode the new file is installed to the right place. There's no security-sensible information in this file, unlike, say, /etc/shadow which has to have restrictive permissions, -- this file only contains two settings used by X setuid wrapper, which are also available from debconf database. It is not usually a problem to have that file mode 0600. But this becomes problematic when, for example, the client is run off an NFS root (where I've actually hit this issue). And generally, non- security-sensitive files aren't created with mode 0600. The fix is trivial: tempfile now has -m MODE argument, so replacing NEW_XWRAPPER_CONFIG=$(tempfile) with NEW_XWRAPPER_CONFIG=$(tempfile -m 0644) is enough. So I'm tagging this as patch available :) This bug is very old, it's here since xfree86-4.3.0 (Jul 2004) or even pre-dates that. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100512092104.25519.19216.report...@gandalf.local
Bug#578406: embedded checks and fallback: apparently wrong solution
Package: compiz Version: 0.8.4-3 Severity: normal 0.8.4-1 (debian version) dropped compiz-manager script and implemented everything in compiz binary. I mean the patch taken from ubuntu, debian/patches/060_move_checks_to_compiz.patch . Now, there are 2 problems with this approach: 1. It is not possible to specify the fallback window manager. The guesswork done in launchFallbackWM() is childish, there should be some option to actually specify what to run, if at all. Maybe for some default it's remotely acceptable, but not for a ultimate solution. For example, I'm running LXDE, and it is opening me xterm, and there's no way to specify what to run instead (and no, I don't want to run metacity or kwin). 2. There's a limitation of max texture size in most radeon cards, which is 2048. Which means that in case a (virtual) resolution of the screen is 2048 (which is not uncommon), new compiz will refuse to start. Previously compiz-manager has a feature to SKIP_CHECKS and run compiz anyway. Now that feature does not exist anymore. Just today we were discussed this problem on irc with some ubuntu user, -- the prob was nautilus trying to display background picture. The solution for that user was to recompile compiz without the above-mentioned patch and specify SKIP_CHECKS. (It is because almost all radeon cards actually works just fine with larger texture sizes). For the case 1 above, I'm not sure that running a fallback WM is any good idea at all, at least from the compiz binary itself (I'm not talking about the case 2 here). How about just exiting with some known exit code, and have a small wrapper script that does all the guesswork (if needed) and can be modified and is at least transparent for the users? Note that it took me quite some energy (and several new non-friends in #compiz) to figure out that the problem is actually in debian changes and not in original compiz... Some background on all this: I run diskless workstations (X terminals) here off a single image, and they're run compiz if available, so there should be a way to fall back to a _specified_ WM in case compiz does not see enough hardware support. Also, when logging in remotely compiz refuses to start and i'm getting WM-less environment as the result, and I'm logging in remotely to my home machine quite often -- from a notebook which I use just as an X terminal, because all my files and my other environment is on my main PC and it is multi-user machine. So in both this scenarios, I need reliable fallback. Which does not exist in debian version but is quite easy to get in official compiz. Thanks! -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (60, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.33-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.8.4-3OpenGL window and compositing mana ii compiz-gnome 0.8.4-3OpenGL window and compositing mana ii compiz-gtk0.8.4-3OpenGL window and compositing mana ii compiz-plugins0.8.4-3OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.4-2Compizconfig Settings Manager -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419162733.11611.73202.report...@gandalf.local
Bug#578416: compiz disallows binding commands to Ctrl+Escape, or Any+Escape, and Return
Package: compiz Version: 0.8.4-3 Severity: normal Tags: patch Escape and Return keys in compiz are special. Even if it is possible to create keybindings for, say, Ctrl+Escape (quite common key shortcut for Main Menu), it will be ignored. This is because the two keys mentioned are checked and catched before everything else, regardless of any modifiers. The attached patch fixes this by treating the keys specially (it's cancel and commit functions) only _without_ usual modifiers, if key were hit together with at least some modifier it is not treated as special (and performing the special function too). This way, we lose, say, Ctrl+Escape or Shift+Return built-in functionality -- before, such combinations were worked just like plain Escape and Return. I'm not sure it's any useful. But at least we're now able to assign some commands to them. Thanks! /mjt -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (60, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.33-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.8.4-3OpenGL window and compositing mana ii compiz-gnome 0.8.4-3OpenGL window and compositing mana ii compiz-gtk0.8.4-3OpenGL window and compositing mana ii compiz-plugins0.8.4-3OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.4-2Compizconfig Settings Manager -- no debconf information compiz-0.8.4-enable-mod+escape-control-keys.diff Currently, compiz treats two particular keyboard keys specially: these are Escape and Return. Regardless of any modifiers or any commands/actions assigned to these keys, they always assigned two particular actions: Cancel and Commit. This disallows using these keys (with or without any or all together modifiers) to bind commands. For example, quite frequent key combination to bring up Main Menu is Ctrl+Escape, which does not work in compiz. The following trivial two-liner patch only treats them specially without any modifier. If there is some modifier key hit too, the keys are treated normally as all other keys, thus allowing one to assign a command to that key sequence. Signed-Off-By: Michael Tokarev m...@tls.msk.ru --- compiz-0.8.4/src/event.c.orig 2010-04-19 17:25:36.677931239 + +++ compiz-0.8.4/src/event.c2010-04-19 17:27:06.004697317 + @@ -376,9 +376,9 @@ triggerKeyPressBindings (CompDisplay *d, unsigned intmodMask = REAL_MOD_MASK ~d-ignoredModMask; unsigned intbindMods; -if (event-keycode == d-escapeKeyCode) +if (event-keycode == d-escapeKeyCode !(event-state modMask)) state = CompActionStateCancel; -else if (event-keycode == d-returnKeyCode) +else if (event-keycode == d-returnKeyCode !(event-state modMask)) state = CompActionStateCommit; if (state) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419175015.00b6112...@gandalf.tls.msk.ru
