Bug#895649: inkscape: Segfault closing dialog after importing PDF
I just ran into (and resolved) this. It appears to be a packaging /
dynamic-linking problem. Fundamentally, it seems that inkscape is not
compatible with having multiple versions of libpoppler present and
usable. This also explains why this issue is so consistent for the
people who encounter it, but never occurs for the people who don't
encounter it.
My first thought, on seeing the ldd output in this bug, was "isn't it
weird that inkscape is picking up two different versions of the same
library?" This turned out to be the fundamental issue.
My ldd output looked like this when I was experiencing the crash:
$ldd /usr/bin/inkscape | grep poppler
libpoppler.so.82 => /usr/lib/x86_64-linux-gnu/libpoppler.so.82
(0x7f09b1c4b000)
libpoppler-glib.so.8 =>
/usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 (0x7f09b19ef000)
libpoppler.so.72 => /usr/lib/x86_64-linux-gnu/libpoppler.so.72
(0x7f09a8e74000)
I then checked to see which versions of libpoppler were installed. It
was a whole bunch of them:
15:20:51> [xsdg{angular}@/usr/lib/x86_64-linux-gnu]
$dpkg -S libpoppler*
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
libpoppler-cpp-dev:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-cpp0v5:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so.0.3.0
libpoppler-glib-dev: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
libpoppler-glib8:amd64: /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8.9.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler-dev:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler64:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.64.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68
libpoppler68:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.68.0.0
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72
libpoppler72:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.72.0.0
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73
libpoppler73:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.73.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74
libpoppler74:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.74.0.0
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80
libpoppler80:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.80.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82
libpoppler82:amd64: /usr/lib/x86_64-linux-gnu/libpoppler.so.82.0.0
I uninstalled all of the deprecated versions and upgraded to the latest:
(excerpt from /var/log/aptitude):
[REMOVE (PURGE)] libpoppler64:amd64 0.48.0-2
[REMOVE (PURGE)] libpoppler68:amd64 0.57.0-2
[REMOVE (PURGE)] libpoppler72:amd64 0.61.1-2
[REMOVE (PURGE)] libpoppler73:amd64 0.62.0-2
[REMOVE (PURGE)] libpoppler74:amd64 0.63.0-2
[REMOVE (PURGE)] libpoppler80:amd64 0.69.0-2
[UPGRADE] gir1.2-poppler-0.18:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-cpp-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-cpp0v5:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-dev:amd64 0.61.1-2 -> 0.71.0-6
[UPGRADE] libpoppler-glib-dev:amd64 0.61.1-2 -> 0.71.0-6
Bug#906731: gimp: liblcms2-2 dependancy should be >= 2.9 not 2.2x.
I just upgraded to gimp 2.10.6 and saw this as well. --xsdg
Bug#748805: System fails to boot after upgrading to linux-image-3.14-0.bpo.1-amd64 from wheezy-backports
I'm seeing this also. I ran a fresh Wheezy install, which installed a 3.2 kernel that continues to work properly. While doing so, I created two partitions, both with btrfs, for / and /home. I completed the install and everything worked fine. Then I immediately did a dist-upgrade to unstable, which included an upgrade to the 3.14 kernel. Thank goodness, it left the 3.2 kernel installed. If I try to boot with the 3.14 kernel, I see the unknown symbol error consistently. If I switch back to the 3.2 kernel, it consistently works fine. On a whim, I tried update-initramfs, which didn't seem to help anything. So my best guesses are that the btrfs module in the packaged 3.14 kernel is miscompiled, or that they have a dependency which wasn't properly marked in modules.dep. Either way, this is a definite issue, and is blocking me from continuing my install. Next step for me is to compile the kernel myself, but obviously the packaged kernel should work properly. --xsdg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748805: Info received (Bug#748805: System fails to boot after upgrading to linux-image-3.14-0.bpo.1-amd64 from wheezy-backports)
Okay, I'm at the machine again, so specific versions $ COLUMNS=80 dpkg -l '*linux-image*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= un linux-imagenone none (no description available) ii linux-image-3. 3.14.4-1 amd64Linux 3.14 for 64-bit PCs ii linux-image-3. 3.2.57-3 amd64Linux 3.2 for 64-bit PCs ii linux-image-am 3.14+57 amd64Linux for 64-bit PCs (meta-packag $ md5sum /lib/modules/3.14-1-amd64/kernel/fs/btrfs/btrfs.ko ac42fd97562b33a0bfa251f70af7a642 /lib/modules/3.14-1-amd64/kernel/fs/btrfs/btrfs.ko $ md5sum /boot/vmlinuz-3.14-1-amd64 e2e8e6bb8c63dff05316bed2c6257797 /boot/vmlinuz-3.14-1-amd64 --xsdg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491511: Acknowledgement (off-by-one: parted should consider cylinders one-indexed rather than zero-indexed)
This is actually worse than I suspected. The logic for setting the start cylinder and setting the end cylinder behave _differently_ on this account: 01:49:22 [EMAIL PROTECTED] #parted /dev/sdc unit cyl p Model: ATA MAXTOR STM332062 (scsi) Disk /dev/scsi/host3/bus0/target0/lun0/disc: 38913cyl Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 38913,255,63. Each cylinder is 8225kB. Partition Table: msdos Number Start End Size Type File system Flags 01:49:24 [EMAIL PROTECTED] #parted /dev/sdc unit cyl mkpart Partition type? primary/extended? p File system type? [ext2]? xfs Start? 1 End? 1216 Information: You may need to update /etc/fstab. 01:49:42 [EMAIL PROTECTED] #parted /dev/sdc unit cyl print Model: ATA MAXTOR STM332062 (scsi) Disk /dev/scsi/host3/bus0/target0/lun0/disc: 38913cyl Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 38913,255,63. Each cylinder is 8225kB. Partition Table: msdos Number Start End Size Type File system Flags 1 1cyl 1215cyl 1215cyl primary 01:49:45 [EMAIL PROTECTED] #fdisk -l /dev/sdc Disk /dev/sdc: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000385a6 Device Boot Start End Blocks Id System /dev/sdc1 21216 9759487+ 83 Linux --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487695: gimp dies after glib tries to allocate lots of memory
Ari Pollak wrote: xsdg wrote: I'm admittedly not sure if this is a gimp problem or a glib problem. Also, I have no idea how I might reproduce this, but hopefully the symptoms will suggest where to look. Unfortunately I don't really know what to do with this bug without steps to reproduce or a backtrace. Yeah, that is tricky. Maybe drop it to wishlist and forward upstream? I guess the hope is to have a datapoint there in case someone else runs into a similar issue, or in case someone stumbles upon some codepath that leads to passing a negative size for glib to allocate? I don't think there's any real way to go after this right now, but I also think it's useful to document it so that other folks can put 2 and 2 together later on down the line. --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464082: dhcp3-client: 3.1.1 seems to fix this issue
Hi, all I was running dhcp3-client 3.1.0-5 with dhcp3-common 3.1.0-5, and just ran into this issue when I tried to supersede the (corrupted?) search value that consistently ended up in my resolv.conf. I upgraded to 3.1.1-1, and it seems to work fine now. My config file (uncommented stuff) is as follows: supersede domain-search mit.edu; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, netbios-name-servers, netbios-scope, interface-mtu; --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483397: iceweasel: latest xulrunner update leaves iceweasel broken
To confirm, it seems like firefox 1.9~rc1-1 hasn't been built for alpha, i386, powerpc, or sparc (all of which 1.9~b5-4 supports). The problem is that 1.9~b5-4 was packaged before there was an xulrunner-1.9 which reported version 1.9. As the folks in #granparadiso on irc.mozilla.org told me, version 1.9 is considered greater than version 1.9b5. So a temporary fix is just to change the maxVersion line from 1.9b5 to 1.9 in /usr/lib/iceweasel/application.ini . This gets firefox running for me locally. --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463962: Upgrade to 1.4.6.dfsg1-3 makes AFS unusable on i386
severity 463962 important thanks Package: openafs-modules-source Version: 1.4.6.dfsg1-3 I upgraded to 1.4.6.dfsg1-3 on my i386 machine (Athlon 64 with 32-bit kernel and userspace), and now I can only use authenticated AFS intermittently. Same errors as the original reporter mentioned. Oddly enough, my Athlon 64/X2 machine running with a 64-bit kernel and userspace works great with 1.4.6.dfsg1-3 against kernel 2.6.24.3. I believe 1.4.6 worked fine against kernel 2.6.15, but I may have upgraded from 1.4.4 to 1.4.6 when I upgraded kernels (I forget exactly). In terms of effects, this can cause getting AFS tokens to fail. Unauthenticated AFS seems like it may be unaffected (or at least mostly so). Oddly, it seems the failure is intermittent (note that the kernel log messages happen in all cases). I had been seeing the following behavior consistently: $kinit -r7d -l1d [EMAIL PROTECTED] aklog athena Password for [EMAIL PROTECTED]: aklog: unable to obtain tokens for cell athena.mit.edu (status: 11862788). However, after recompiling (from the exact same source tree), and stopping and starting openafs-client, getting tickets and tokens seems to work fine now: $kinit -r7d -l1d [EMAIL PROTECTED] aklog athena Password for [EMAIL PROTECTED]: $ i386 machine (works intermittently): $uname -a Linux perl 2.6.24.3 #2 PREEMPT Sun Mar 9 09:54:16 UTC 2008 i686 GNU/Linux $dpkg -l *openafs* | grep ^ii | cut -b1-72 ii openafs-client1.4.6.dfsg1-3 AFS dis ii openafs-krb5 1.4.6.dfsg1-3 AFS dis ii openafs-modules-2.6.101.3.81-5+2.6.10-0 The AFS ii openafs-modules-2.6.10-ng 1.4rc1-1+2.6.10-ng-0 The AFS ii openafs-modules-2.6.12-ng 1.4rc4-1+2.6.12-ng-0 The AFS ii openafs-modules-2.6.151.4.0-3+2.6.15-0 AFS dis ii openafs-modules-2.6.24.3 1.4.6.dfsg1-3+2.6.24.3-0 AFS dis ii openafs-modules-source1.4.6.dfsg1-3 AFS dis amd64 machine (works fine): $uname -a Linux intercal 2.6.24.3 #2 SMP PREEMPT Wed Mar 5 19:39:03 UTC 2008 x86_64 GNU/Linux $dpkg -l *openafs* | grep ^ii | cut -b1-72 ii openafs-client 1.4.6.dfsg1-3 AFS dist ii openafs-krb5 1.4.6.dfsg1-3 AFS dist ii openafs-modules-2.6.22.9 1.4.4.dfsg1-7+2.6.22.9-0 AFS dist ii openafs-modules-2.6.24.3 1.4.6.dfsg1-3+2.6.24.3-0 AFS dist ii openafs-modules-source 1.4.6.dfsg1-3 AFS dist --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468272: Thunderbird 2.0.0.12 released
Package: icedove Version: 2.0.0.9-3 Severity: wishlist Thunderbird 2.0.0.12 was released, and fixes a number of security issues. --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463815: Upgrade makes xfce4-sensors-plugin unusable
severity 463815 grave thanks I upgraded from 0.10.99.2-1 to 0.10.99.4~svn-r3775-1 and now xfce4-sensors-plugin starts, complains about hddtemp failing on /dev/fd0, and exits. Running from the command line confirms what xfce4-sensors-plugin reported, but it's stupid to try to get a temperature off the floppy drive in the first place. 16:02:04 [EMAIL PROTECTED] $hddtemp /dev/fd0 ERROR: /dev/fd0: can't determine bus type (or this bus type is unknown) 16:02:11 [EMAIL PROTECTED] $echo $? 1 --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445172: [Pkg-xfce-devel] Bug#445172: xfce4: XFCE doesn't register keyboard shortcuts on startup; acts as if Alt were constantly pressed
Simon Huggins wrote: ::snip? SNIP!:: Hrm, how bizarre. Your locale is en_US is there anything odd about your keyboard setup in your X config? Can you give us the lines you have? I've attached my X config. I'm currently running with the binary driver, though the problem persists regardless of whether I use nv or nvidia. Do you have any Xmodmap files or any other local keyboard config that might be getting in the way? Not that I'm aware of. This was a clean install when I ran into the problem Note that I installed the Debian base and then installed everything else by hand with apt-get/aptitude. This has worked flawlessly on a number of machines I've set up in the past, which is why I'm so confused. Does this still happen if you just use startx? It does happen if I still use startx. I noticed that if I merely kill xfce-mcs-manager and xfwm4 and start them over again (without touching any settings stuff), it just starts working properly. And as a new development, when I start X, xfwm4 either isn't started or dies immediately. I have no idea whether or not this is related to the original problem or something different. Nonetheless, as I noted above, once I start it manually (from a terminal), it works as expected. Actually, now that I think about it, I believe the xfwm4 not starting properly happened about when I added the composite stanza to my xorg.conf (this in relation to debian bug 445323). --xsdg Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files RgbPath /etc/X11/rgb ModulePath /usr/lib/xorg/modules FontPath /usr/share/fonts/X11/misc FontPath /usr/share/fonts/X11/cyrillic FontPath /usr/share/fonts/X11/100dpi/:unscaled FontPath /usr/share/fonts/X11/75dpi/:unscaled FontPath /usr/share/fonts/X11/Type1 FontPath /usr/share/fonts/X11/100dpi FontPath /usr/share/fonts/X11/75dpi FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Load dbe Load glx Load record Load xtrap Load extmod Load dri Load GLcore EndSection Section InputDevice Identifier Keyboard0 Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us Option XkbCompat EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model VertRefresh 40-150 HorizSync 31.5-64.3 DisplaySize 324 243 EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option SWcursor # [bool] #Option HWcursor # [bool] #Option NoAccel # [bool] #Option ShadowFB # [bool] #Option UseFBDev # [bool] #Option Rotate# [str] #Option VideoKey # i #Option FlatPanel # [bool] #Option FPDither # [bool] #Option CrtcNumber# i #Option FPScale # [bool] #Option FPTweak # i #Option DualHead # [bool] Identifier Card0 # Driver nv Driver nvidia VendorName nVidia Corporation BoardName G72 [GeForce 7300 SE] BusID PCI:2:0:0 EndSection Section Screen Identifier Screen0 Device Card0 Monitor Monitor0 DefaultDepth24 SubSection Display Depth 16 Modes 1280x960 EndSubSection SubSection Display Depth 24 Modes 1280x960 EndSubSection EndSection Section DRI Mode0666 EndSection Section Extensions Option Composite Disable EndSection
Bug#445323: [Pkg-xfce-devel] Bug#445323: cpu-intensive window, redraw/window resize
Mathias: I'm not sure, as I haven't poked at composite at all up to now. This seems to describe a possibly-related situation (though, I'm not sure why the status is still New, given that it was reported against 7.1) https://bugs.freedesktop.org/show_bug.cgi?id=8499 --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445323: cpu-intensive window redraw/window resize
I am 99% sure this is an X problem. (Written before experimenting): I'm currently experiencing this problem on one of my machines, and am fairly certain it's an xorg-related problem. I have the same versions of xfce4-terminal, libvte9, and libvte-common on both machines. One machine is running xserver-xorg version 1:7.0.22 (which doesn't demonstrate the problem), and the other is using version 1:7.3+2 (and does show the problem). (After experimenting): I just upgraded the unaffected box to 1:7.3+2 and slow xfce4-terminal drawing started happening on it as well. To be clear, the packages and versions changed during the upgraded follow: [INSTALL] dmidecode [UPGRADE] gcc-4.2-base 4.2-20070609-1 - 4.2.1-6 [UPGRADE] libgcc1 1:4.2-20070609-1 - 1:4.2.1-6 [UPGRADE] libsensors3 1:2.10.1-2 - 1:2.10.4-3 [UPGRADE] libstdc++6 4.2-20070609-1 - 4.2.1-6 [UPGRADE] libxfont1 1:1.0.0-4 - 1:1.3.1-1 [UPGRADE] lm-sensors 2.5.4-5 - 1:2.10.4-3 [UPGRADE] xserver-xorg 1:7.0.22 - 1:7.3+2 [UPGRADE] xserver-xorg-core 1:1.0.2-8 - 2:1.4-3 [UPGRADE] xserver-xorg-input-kbd 1:1.0.1.3-2 - 1:1.2.2-3 [UPGRADE] xserver-xorg-input-mouse 1:1.0.4-3 - 1:1.2.2-6 [UPGRADE] xserver-xorg-video-nv 1:1.0.1.5-2 - 1:2.1.5-1 [UPGRADE] xserver-xorg-video-tdfx 1:1.1.1.3-3 - 1:1.3.0-6 Furthermore, gqview seems to be affected by the same problem (that is, redraws of its image-showing space seem to occur much more slowly than before the upgrade). --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385501: regression: maximize horizontally and maximize vertically should function independently
Eulex from irc.freenode.org/#xfce confirmed this for 4.3.9.2 in testing and reported that the behavior is back to that of 4.3.9.1 in svn. So I haven't verified directly, but this might be fixed upstream. --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249315: XFS warning should be displayed more prominently
On Mon, 2005-05-16 at 16:51, Russ Allbery wrote: xsdg [EMAIL PROTECTED] writes: ::snip? SNIP!:: Secondly, something, somewhere, recognized that the cache was on an XFS partition, but only warned me after I was unable to do anything. From re-reading the original report, it appears that this warning has been added since then. The only thing that's changed so far as I know is the documentation in README.modules. I don't believe there's any way of detecting in advance whether the system calls are going to fail, since those details are rather buried in the kernel. This would probably be an upstream question, but is there no way to check for a null pointer before dereferencing it? I'm not familiar with kernel or AFS coding, but it seems like calling a function on faith with an inconsistent API is asking for problems. I'm not sure what message you might have received about this, or what might have produced it. A grep doesn't seem to turn up anything in the OpenAFS source that would have produced such a warning. I'll try to duplicate it over this coming weekend or early-ish next week. --xsdg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
