Bug#1063997: bindfs: consider providing mount.bindfs
I don't know whether it's common for other FUSE filesystems to provide these aliases, but there exists a `/usr/sbin/mount.fuse` that gets invoked when `/etc/fstab` mentions a filesystem such as `fuse.bindfs`. On Thu, Feb 15, 2024 at 2:48 PM Helmut Grohne wrote: > Package: bindfs > Version: 1.14.7-1 > Severity: wishlist > > When mounting a filesystem using the standard mount utility (e.g. via > /etc/fstab), it tries to perform the mount by calling out to > "mount.$FSTYPE" when it does not know how to mount the particular > filesystem type already. As it happens, bindfs does not belong to those > types that mount understands. Unfortunately, it also does not provide a > mount.bindfs on /usr/sbin. Therefore mount fails to forward to bindfs. > Would it be reasonable to provide a symlink /usr/sbin/mount.bindfs -> > ../bin/bindfs to make this work? Whether you do this or not, please > close this bug after having made a decision. > > Helmut > >
Bug#951208: fuse3's backwards compatibilty (Re: Bug#951208: Impossible to mount over nonempty directories)
I've used non-empty mountpoints a few times, mostly when mounting a directory onto itself, but I have no idea how popular that use case really is. Mounting to a new empty location is probably always possible, but it's sometimes quite undesirable or inconvenient: - Sometimes I want to enforce certain rules on a directory and hide the original directory to prevent confusion and misuse. - Sometimes I want to quickly test something on an existing directory, and a program I want to use might be configured or even hard-coded to use that specific directory. So I think this is worth fixing. Here's my current understanding (I was a bit confused in my initial response): - The scope: bindfs seems to work fine with libfuse2 and fuse3 EXCEPT for `nonempty`. The test suite, which tests most other features, passes on Debian 10 with fuse3 installed. - The bug: libfuse2 checks that the destination is empty or `nonempty` is given. Then it invokes fusermount (symlinked to fusermount3), which doesn't accept `nonempty`. - bindfs cannot be compiled against libfuse3. That would require significant code changes. So it seems backwards compatibility between fusermount3 and libfuse2 was intended, and this is a bug there. If so, here are the "easy" fixes I can think of: 1. patch fusermount3 to accept and ignore `nonempty` (perhaps only when invoked through a symlink named fusermount?) or 2. patch libfuse2 to stop requiring `nonempty` (or passing it to fusermount when it's symlinked to fusermount3?) or 3. instead of symlinking fusermount -> fusermount3, make it a wrapper script that drops `nonempty` from any option list like `-o option1,nonempty,option2,...` If someone who knows FUSE better can point out something simple I can do in bindfs code instead, I'd be happy to write a short patch. But there may be other FUSE 2 filesystems designed to "wrap" an existing directory that also have this bug, so I think fixing this at the FUSE layer is better. On Tue, 18 Feb 2020 at 15:12, Eugene V. Lyubimkin wrote: > Hello, > > Martin Pärtel kirjoitti 17.2.2020 klo 10.49: > > I'm unfortunately unlikely to have time to port bindfs to FUSE 3 in the > near future :( > > > > The easiest distro-level workaround in terms of "least code required" > would probably be to patch fuse3's fusermount to > > allow and ignore `nonempty` (and maybe print a deprecation warning). Or > some hacks could probably be invented to direct > > FUSE 2 filesystems to use FUSE 2 helpers. It's up to the Debian > maintainers whether they want the maintenance burder of > > either of these workarounds. > > CC'ing FUSE's maintainer for extra input if any. > > > From the discussion above I gather that bindfs is still (with limitations) > usable with fuse3. If true, then I wouldn't > like to block users of fuse3 from using bindfs via strict Depends. I could > add Suggests or Recommends on fuse2, > though. > > How common of a use case is to use bindfs with a non-empty mount point? I > never mounted filesystems like that myself, so > I don't know if it's a minor nuisance with an easy workaround, or a > significant limitation making some use case > unachievable. > > > Regards, > -- > Eugene V. Lyubimkin aka JackYF > C++ GNU/Linux userspace developer, Debian Developer > >
Bug#951208: Impossible to mount over nonempty directories
Ok, thanks. If you don't use other FUSE filesystems, you can maybe uninstall `fuse3` and install `fuse`. I'm unfortunately unlikely to have time to port bindfs to FUSE 3 in the near future :( The easiest distro-level workaround in terms of "least code required" would probably be to patch fuse3's fusermount to allow and ignore `nonempty` (and maybe print a deprecation warning). Or some hacks could probably be invented to direct FUSE 2 filesystems to use FUSE 2 helpers. It's up to the Debian maintainers whether they want the maintenance burder of either of these workarounds. On Wed, 12 Feb 2020 at 18:07, Willem Mulder wrote: > Hi Martin, > > On Wed, 2020-02-12 at 17:17 +0200, Martin Pärtel wrote: > > If that doesn't help, maybe you're running a mixed environment where > > e.g. bindfs is compiled against FUSE 2 but the system runs FUSE 3 > > helper binaries? The version list at the end of your e-mail suggests > > this. > > I haven't used your option, but I can confirm (using `ldd > /usr/bin/bindfs` and `fusermount -V`) that bindfs was linked against > libfuse 2.9.9, and the helper binaries are version 3.7.0. I guess the > package either needs to limit the FUSE version to < 3, or link against > libfuse >= 3. > > Kind regards, > > Willem Mulder >
Bug#951208: Impossible to mount over nonempty directories
Hi Willem, The only reference to "nonempty" in binds code is when a directory is mounted on itself. In that case bindfs adds `-ononempty` automatically. I changed it so it doesn't on FUSE 3: https://github.com/mpartel/bindfs/commit/2c2337b7c9b87744662c4b08d453bf7128444f43 (git master, not in a release yet) If that doesn't help, maybe you're running a mixed environment where e.g. bindfs is compiled against FUSE 2 but the system runs FUSE 3 helper binaries? The version list at the end of your e-mail suggests this. I added an option that may help you debug that: https://github.com/mpartel/bindfs/commit/4b87500fef925e591b08cb8aea6bf0a21b84dd72 Let me know if I can help further. On Wed, 12 Feb 2020 at 16:27, Willem Mulder wrote: > Package: bindfs > Version: 1.14.1-1 > Severity: normal > File: /usr/bin/bindfs > > Dear Maintainer, > > Currently, it's not possible for me to mount over nonempty directories. > BindFS insists I have to use -o nonempty: > > fuse: mountpoint is not empty > fuse: if you are sure this is safe, use the 'nonempty' mount option > > But when I do, I get the following message: > > fusermount: unknown option 'nonempty' > > Some quick searching suggests this might have to do with upgrading to > FUSE 3: https://github.com/rclone/rclone/issues/3562 > > Kind regards, > > Willem Mulder > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), > (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-3-amd64 (SMP w/16 CPU cores) > Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), > LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages bindfs depends on: > ii fuse3 [fuse] 3.7.0-1 > ii libc6 2.29-10 > ii libfuse2 2.9.9-2 > > bindfs recommends no packages. > > bindfs suggests no packages. > > -- no debconf information > >
Bug#681647: bindfs: Invalid memory access
Thanks Marcelo. It's embarassing how many memory bugs I've put into
bindfs recently.
1.10.7 should be clean (ran test suite with valgrind), but if you want
to base off 1.10.3 due to a feature freeze or something, then please use
the attached two patches instead. One is a more comprehensive fix to
readdir that can handle any failure of pathconf for any reason. The
other fixes another serious memory error in 1.10.3.
Thanks and my apologies.
Martin
--- bindfs-1.10.3/src/bindfs.c 2012-05-18 16:45:33.0 +0300
+++ bindfs-new/src/bindfs.c 2012-07-15 12:12:39.748468808 +0300
@@ -54,6 +54,7 @@
#include assert.h
#include pwd.h
#include grp.h
+#include limits.h
#ifdef HAVE_SETXATTR
#include sys/xattr.h
#endif
@@ -399,9 +400,16 @@
struct dirent *de;
struct stat st;
int result = 0;
-(void) path;
+long pc_ret;
-de_buf = malloc(offsetof(struct dirent, d_name) + pathconf(path, _PC_NAME_MAX) + 1);
+path = process_path(path);
+
+pc_ret = pathconf(path, _PC_NAME_MAX);
+if (pc_ret 0) {
+DPRINTF(pathconf failed: %d, errno);
+pc_ret = NAME_MAX;
+}
+de_buf = malloc(offsetof(struct dirent, d_name) + pc_ret + 1);
seekdir(dp, offset);
while (1) {
--- bindfs-1.10.3/src/usermap.c 2012-05-18 16:45:33.0 +0300
+++ bindfs-1.10.4/src/usermap.c 2012-06-18 08:57:55.0 +0300
@@ -44,7 +44,11 @@
return usermap_status_ok;
}
if (map-user_size == map-user_capacity) {
-map-user_capacity *= 2;
+if (map-user_capacity == 0) {
+map-user_capacity = 8;
+} else {
+map-user_capacity *= 2;
+}
map-user_from = (uid_t*)realloc(map-user_from, map-user_capacity * sizeof(uid_t));
map-user_to = (uid_t*)realloc(map-user_to, map-user_capacity * sizeof(uid_t));
}
@@ -65,7 +69,11 @@
return usermap_status_ok;
}
if (map-group_size == map-group_capacity) {
-map-group_capacity *= 2;
+if (map-group_capacity == 0) {
+map-group_capacity = 8;
+} else {
+map-group_capacity *= 2;
+}
map-group_from = (gid_t*)realloc(map-group_from, map-group_capacity * sizeof(gid_t));
map-group_to = (gid_t*)realloc(map-group_to, map-group_capacity * sizeof(gid_t));
}
Bug#681647: bindfs: Invalid memory access
Note that I added process_path to the revised patch, it's not the same code that was in 1.10.6. In 1.10.6 pathconf still failed for exactly the reason you described, but defaulting to NAME_MAX always saved the day. I feel quite stupid for staring at it for so long and not seeing the missing process_path :) On 07/15/2012 03:41 PM, Marcelo E. Magallon wrote: Hi Martin, thanks for the patches! About the readdir one, I saw that change in the newer releases, and even if I can see why it works, I'm not convinced it's correct. As you already know, FUSE sends something like /src in the path argument. When passing that to pathconf, if /src doesn't happen to exist in the global hierarchy, pathconf will return -1 because it can't determine the corresponding filesystem's limits. If by chance it _does_ happen to exist, it won't necessarily return a correct value, because it's comparing /src vs /something/else/src. If, say, /something is on a different filesystem, then the information for /src and /something doesn't necessarily match. By using process_path, you are turning the absolute path into a relative one wrt to the original filesystem, and everything works as expected. So, unless I'm missing something, the call to pathconf will fail most of the time and the code will be using the fallback value most of the time, which is obviously not your intention. Again, many thanks! Marcelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634456: bindfs: uninstallable on kfreebsd-i386 or kfreebsd-amd64
For the record, I posted http://www.freebsd.org/cgi/query-pr.cgi?pr=159102 and put a sleep-if-bsd in the test suite for the eventual next release ( https://github.com/mpartel/bindfs/commit/1479a6bb7184009b440a2e68b792941de1bd1f76 ). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634456: bindfs: uninstallable on kfreebsd-i386 or kfreebsd-amd64
Hi Robert and Eugene, bindfs doesn't hardcode fusermount. It works with MacFUSE, which also doesn't have fusermount and uses umount for unmounts. However, on Linux fusermount had better be installed or else a regular user can't unmount (and probably not mount) anything not in fstab. If either of you has access to a BSD installation, you can download the bindfs source and do ./configure make make check# requires ruby sudo make check The test suite mounts bindfs like a regular user without writing to fstab and unmounts either with fusermount -u (if installed) or umount. If the tests pass as both a regular user and as root then all should be well. On 07/21/2011 08:02 PM, Robert Millan wrote: Hi Eugene, 2011/7/21 Eugene V. Lyubimkinjac...@debian.org: Recommends: fuse [linux-any] That choice is nearest among others I guess, but shouldn't that be Recommends: fuse [linux-any] | fuse4bsd [kfreebsd-any] like in 'Depends' choice? Am I right that /usr/bin/mount_fusefs (provided by fuse4bsd) is needed for mounting fuse filesystems from the /etc/fstab entries? It depends on what bindfs does. fuse4bsd doesn't provide fusermount command. Equivalent functionality is accessible via umount, but if bindfs requires specifically fusermount, that won't work. So the questions would be: Does bindfs hardcode fusermount and attempt to run this command? If it does, can it be adapted to use umount on GNU/kFreeBSD? If not, is it essential that fusermount is available? If its use is not essential, then Recommends would do. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634456: bindfs: uninstallable on kfreebsd-i386 or kfreebsd-amd64
On 07/21/2011 09:21 PM, Robert Millan wrote: It should be noted that unlike the GNU/Linux version, FUSE may only be used as root on Debian GNU/kFreeBSD. This is relevant for the Debian package maintainer because the testsuite should only be run when DEB_HOST_ARCH_OS = linux. Or only run the test suite as root on kFreeBSD, if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634456: bindfs: uninstallable on kfreebsd-i386 or kfreebsd-amd64
On 07/21/2011 09:46 PM, Robert Millan wrote: Testsuite fails. I just installed a virtualized kFreeBSD to debug that. With fuse4bsd the mount appears too late. Unlike with Linux, it appears after bindfs has backgrounded and sometimes even after the mount appears in `mount` :/ In any case, if I put a sleep 1 before each test, they all pass, so yay :) I'll try to find a solution for the test suite and have it in the next release, whenever that will be. I'll make it sooner if Eugene wants to start running the test suite in the Debian build. Actually this might be a bug worth reporting to fuse4bsd, since it's problematic for scripts that first mount something and then use it. But is the project even alive anymore? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560126: xserver-xorg-video-radeon: Launching GL Apps Corrupts System
Same problem on an old desktop system with an ATI Radeon 9250 5960 (AGP). The system worked perfectly otherwise before I switched from a GeForce 2 to the ATI card, hoping for better driver support (*sigh*). The system was initially running lenny, but all GL apps would segfault the X server. I then upgraded the xserver packages to those in sid and ended up in this situation (x11-common couldn't be updated because of dependencies). 6 passes (7 hrs) of memtest revealed no errors. X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30.8-dsa-ia32 i686 Debian Current Operating System: Linux hiie 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686 Build Date: 13 October 2009 11:25:51AM xorg-server 2:1.6.5-1 (bui...@murphy.debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Dec 22 11:51:39 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Generic Monitor (**) | |--Device Generic Video Card (**) Option DontZap off (**) Option AIGLX off (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/X11R6/lib/X11/fonts/misc does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/100dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/75dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/Type1 does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/75dpi does not exist. Entry deleted from font path. (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist. Entry deleted from font path. (**) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins (==) ModulePath set to /usr/lib/xorg/modules (**) Extension Composite is disabled (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0x6c0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (++) using VT number 7 (--) PCI:*(0:1:0:0) 1002:5960:196d:1013 ATI Technologies Inc RV280 [Radeon 9200 PRO] rev 1, Mem @ 0xf000/134217728, 0xde00/65536, I/O @ 0xd800/256, BIOS @ 0x/131072 (II) Open ACPI successful (/var/run/acpid.socket) (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded by default. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded by default. (II) dri will be loaded by default. (II) dri2 will be loaded by default. (II) LoadModule: i2c (II) Module i2c already built-in (II) LoadModule: ddc (II) Module ddc already built-in (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II)
Bug#497050: Still an issue
Still happens. This is also a box that has been upgraded from etch to lenny. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#443250: Confirmed fixed
Works for me now. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443250: xserver-xorg-input-kbd: shift key doesn't work if pressed very quickly after certain letters
Package: xserver-xorg-input-kbd Version: 1:1.2.2-3 Severity: normal After the recent big Xorg update, I started getting mysterious failures while typing quickly a password, which contains the sequence xA. It turned out that if I start holding down left shift very quickly after typing x, the following characters will not be uppercase. This also works with the letters z, c, and v but not, for example, b. Everything works fine outside X, and used to work before the upgrade to Xorg 7.3. Only the left shift key is affected. The bug can be seen in xev. When I press and release x quickly, then quickly press and hold shift, the shift event takes a moment (0.5-1 sec) to register. If I press a while holding the shift key before the shift event registers, it will register as a lowercase a and the shift event will not arrive at all before I release the shift. If I try the same with e.g. b, then the shift event registers immediately. This is on a ThinkPad T60, whose keyboard the KDE control center indentifies as IBM ThinkPad S60Z/600/600E/A22E, Intl. KDE's Enable keyboard layouts option is off, however. The relevant section in xorg.conf: Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout ee EndSection Changing layouts or models doesn't help. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.3 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-kbd depends on: ii libc6 2.6.1-5GNU C Library: Shared libraries ii xserver-xorg-core 2:1.4-2X.Org X server -- core server xserver-xorg-input-kbd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396037: libgl1-mesa-dri: i915 OpenGL severely broken
Could you report this upstream at http://bugs.freedesktop.org, product xorg, component Driver/intel? Thanks. Done. https://bugs.freedesktop.org/show_bug.cgi?id=10586 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396037: libgl1-mesa-dri: i915 OpenGL severely broken
Yeah, sorry, that was a messy post. I hope this one is a bit better. * Behaviour with unstable packages: libdrm2_2.0.2-0.1_i386.deb libdrm-dev_2.0.2-0.1_i386.deb libgl1-mesa-dev_6.5.1-0.6_i386.deb libgl1-mesa-dri_6.5.1-0.6_i386.deb libgl1-mesa-glx_6.5.1-0.6_i386.deb mesa-common-dev_6.5.1-0.6_all.deb xserver-xorg-core_1.1.1-20_i386.deb xserver-xorg-video-i810_1.7.2-4_i386.deb As described in the initial bugreport: OpenGL apps don't work unless LIBGL_ALWAYS_INDIRECT is set. With LIBGL_ALWAYS_INDIRECT I get lots of rendering artifacts (e.g. the sun is missing a quarter of its halo in Celestia, textures blinking in nexuiz). (xserver-xorg-core is the only package that has changed here since the initial bug report. 1.1.1-18 = 1.1.1-20) * Behaviour with old experimental packages from previous e-mail: libdrm2_2.3.0-1_i386.deb libdrm-dev_2.3.0-1_i386.deb libgl1-mesa-dev_6.5.2-3_all.deb libgl1-mesa-dri_6.5.2-3_i386.deb libgl1-mesa-glx_6.5.2-3_i386.deb mesa-common-dev_6.5.2-3_all.deb xserver-xorg-core_1.2.0-4_i386.deb - LIBGL_ALWAYS_INDIRECT causes the exact same rendering bugs but OpenGL programs now work properly _without_ it (although with a warning about a missing visual). - Putting Option XAANoOffscreenPixmaps in the device section fixes at least a bug with Beryl/Compiz where windows don't redraw themselves in texture from pixmap mode. Load dbe in Section module doesn't seem to have any effect after all. * Behaviour with latest experimental packages: xserver-xorg-core_1.2.99.903-1_i386.deb xserver-xorg-video-i810_1.9.93-1_all.deb xserver-xorg-video-intel_1.9.93-1_i386.deb Same as with the previous experimental packages as far as I can tell except for some new issues: - Exiting X or switching to a console VT while beryl is running almost always causes the machine to freeze! - Even when Beryl is not running X prints the following on exit: (EE) intel(0): I830 Vblank PipeSetup Failed 0 - X also always prints the following warning while starting up: (WW) intel(0): xf86AllocateGARTMemory: allocation of 10 pages failed (Cannot allocate memory) - Some of Beryl's Emerald themes render incorrectly. So the best combination for me was: - Mesa 6.5.2-3 - libdrm2_2.3.0-1 - xserver-xorg-core_1.2.0-4 - xserver-xorg-video-i810_1.7.2-4 (the one in unstable) - NO special envvars - Option XAANoOffscreenPixmaps if running Beryl or Compiz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396037: libgl1-mesa-dri: i915 OpenGL severely broken
Hi Brice, Yes, the problem still exists, although with LIBGL_ALWAYS_INDIRECT enabled programs no longer tend to crash. I tried with the following experimental packages: libdrm2_2.3.0-1_i386.deb libdrm-dev_2.3.0-1_i386.deb libgl1-mesa-dev_6.5.2-3_all.deb libgl1-mesa-dri_6.5.2-3_i386.deb libgl1-mesa-glx_6.5.2-3_i386.deb mesa-common-dev_6.5.2-3_all.deb xserver-xorg-core_1.2.0-4_i386.deb xserver-xorg-video-i810-modesetting_1.7.2.git20070210-1_i386.deb (also tried without the modesetting driver; no difference) At first OpenGL apps were much slower and had different (but still ugly) rendering artifacts than before, but after adding Load dbe and Option XAANoOffscreenPixmaps (not sure which one helped, sorry) to xorg.conf the speed went back to normal. Adding those options didn't seem to have change anything after I had reverted back to sid packages. With the experimental packages the LIBGL_ALWAYS_INDIRECT envvar caused the exact same rendering artifacts as with unstable packages. After adding the above options to xorg.conf, things worked perfectly, but only without LIBGL_ALWAYS_INDIRECT. So, the working combination was: - experimental packages (except i810-modesetting) - Load dbe (or Option XAANoOffscreenPixmaps?) - _no_ LIBGL_ALWAYS_INDIRECT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401993: rlwrap: please upgrade to latest version
Package: rlwrap Version: 0.24-1 Severity: normal The current upstream version of rlwrap is 0.28. Please upgrade to that as 0.27 fixed quite a few annoying bugs. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-beyond4 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-15) Versions of packages rlwrap depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libncurses5 5.5-5 Shared libraries for terminal hand ii libreadline5 5.2-1 GNU readline and history libraries rlwrap recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396037: libgl1-mesa-dri: i915 OpenGL severely broken
Package: libgl1-mesa-dri Version: 6.5.1-0.2 Severity: important OpenGL apps are terribly slow or don't work at all unless LIBGL_ALWAYS_INDIRECT is set. e.g. glxgears renders nothing and prints: libGL warning: 3D driver claims to not support visual 0x5b do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. Celestia works but has major rendering artifacts. Many OpenGL apps crash the X server either every time (a Qt4/OpenGL app of mine) or occasionaly (flurry screensaver). A backtrace from one of the crashes: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c4354] 1: [0xe420] 2: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c919b7] 3: /usr/lib/dri/i915_dri.so(__driUtilUpdateDrawableInfo+0xeb) [0xa7798d5b] 4: /usr/lib/dri/i915_dri.so(intelGetLock+0xde) [0xa77b339e] 5: /usr/lib/dri/i915_dri.so(intelClearWithBlit+0x69d) [0xa77b164d] 6: /usr/lib/dri/i915_dri.so(intelClear+0x133) [0xa77b54e3] 7: /usr/lib/dri/i915_dri.so(_mesa_Clear+0x185) [0xa78f38b5] 8: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c70f38] 9: /usr/lib/xorg/modules/extensions/libglx.so(__glXRender+0xf3) [0xb7c68fd3] 10: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c6df6a] 11: /usr/bin/X(Dispatch+0x19b) [0x8086cab] 12: /usr/bin/X(main+0x489) [0x806e699] 13: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7da1ea8] 14: /usr/bin/X(FontFileCompleteXLFD+0xa9) [0x806d9d1] Fatal server error: Caught signal 11. Server aborting Some other interesting lines from Xorg.log: (WW) AIGLX: 3D driver claims to not support visual 0x23 (WW) AIGLX: 3D driver claims to not support visual 0x24 (WW) AIGLX: 3D driver claims to not support visual 0x25 (WW) AIGLX: 3D driver claims to not support visual 0x26 (WW) AIGLX: 3D driver claims to not support visual 0x27 (WW) AIGLX: 3D driver claims to not support visual 0x28 (WW) AIGLX: 3D driver claims to not support visual 0x29 (WW) AIGLX: 3D driver claims to not support visual 0x2a (WW) AIGLX: 3D driver claims to not support visual 0x2b (WW) AIGLX: 3D driver claims to not support visual 0x2c (WW) AIGLX: 3D driver claims to not support visual 0x2d (WW) AIGLX: 3D driver claims to not support visual 0x2e (WW) AIGLX: 3D driver claims to not support visual 0x2f (WW) AIGLX: 3D driver claims to not support visual 0x30 (WW) AIGLX: 3D driver claims to not support visual 0x31 (WW) AIGLX: 3D driver claims to not support visual 0x32 (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so Turning off Composite does not help. There is nothing interesting in dmesg. Hardware: Thinkpad T60 Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-beyond4 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-15) Versions of packages libgl1-mesa-dri depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libdrm2 2.0.2-0.1 Userspace interface to kernel DRM ii libexpat11.95.8-3.3 XML parsing C library - runtime li ii libgl1-mesa-glx 6.5.1-0.2 A free implementation of the OpenG libgl1-mesa-dri recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332545: Same
Same problem here with Warcraft III and a certain Nullsoft installer. wine regedit and winemine for example do work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321291: libatomic-ops-dev: problem with gcc 4.0 -O0
Package: libatomic-ops-dev
Version: 1.0-1
Severity: important
Tags: experimental
The function AO_test_and_set_full fails to build with the following
error:
test.s: Assembler messages:
test.s:38: Error: bad register name `%sil
This only occurs when compiling with the -O0 flag using gcc 4.0.
It did not occur with gcc 3.3 nor does it occur when using -Os,
-O1, -O2 or -O3.
A minimal test file and the exact build command I used are below:
gcc-4.0 -march=i386 -mtune=i386 -O0 -Wall -Wno-long-long -save-temps -c test.c
#include atomic_ops.h
int main()
{
volatile AO_TS_t x = 0;
AO_test_and_set_full(x);
}
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.3
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages libatomic-ops-dev depends on:
ii libatomic-ops 1.0-1 A library for atomic operations
(s
libatomic-ops-dev recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
