Bug#623429: trayer sets crazy strut values
I've reviewed this bug and it appears to still exist in trayer version 1.1.1-1, and indeed in upstream as well. This problem exists in an up-to-date as of today testing system on amd64 using the nouveau X driver. In my experimenting I have determined that rolling back to 1.0-5 fixes the problem for me. I am attaching here several files. First are the xprop outputs from the two versions of trayer. These were obtained from $ trayer --SetPartialStrut true --SetDockType true The difference in the *_STRUT settings is clear. Additionally, I've stuck some debug prints in panel.c which produces the following output: panel_set_wm_strut:70 : ENTER panel_set_wm_strut:103 : raw strut 0 0 0 26 0 0 0 0 0 0 0 1439 panel_set_wm_strut:104 : type 3. width 26. from 0 to 1439 panel_set_wm_strut:121 : strut return: 21917488 panel_set_wm_strut:121 : strut return: 0 panel_set_wm_strut:121 : strut return: 0 panel_set_wm_strut:121 : strut return: 0 panel_set_wm_strut:121 : strut return: 874 panel_set_wm_strut:121 : strut return: 0 panel_set_wm_strut:121 : strut return: -276931072 panel_set_wm_strut:121 : strut return: 32767 panel_set_wm_strut:121 : strut return: 0 panel_set_wm_strut:121 : strut return: 0 panel_set_wm_strut:121 : strut return: 1451580027 panel_set_wm_strut:121 : strut return: 32736 panel_set_wm_strut:124 : RETURN lines 103 and 104 show how panel.c is trying to set the strut values properly for my setup. the lines for 121 show the values extracted back out of the property via XGetWindowProperty. Those strut values somewhat correspond with the xprop result for that particular run: $ xprop | grep STRUT _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 21980368, 0, 874, 4018036224, 0, 1451580027 While it's not a perfect match, it's a close enough match to suggest to me that something fishy is going on in gdk(?). Or that the problem exists somewhere in the infrastructure underlying trayer. I have compared the current debian and upstream versions against the version at http://anonscm.debian.org/hg/collab-maint/oldtrayer/ and the only relevant change I can see is that calls to GDK_DISPLAY() have been replaced with gdk_helper_display(). Currently installed versions of immediate depends of trayer: libatk1.0-0 2.0.0-1 libc6 2.13-4 libcairo2 1.10.2-6 libfontconfig1 2.8.0-2.2 libfreetype6 2.4.4-1 libgdk-pixbuf2.0-0 2.23.3-3 libglib2.0-0 2.28.6-1 libgtk2.0-0 2.24.4-3 libpango1.0-0 1.28.3-6 libx11-6 2:1.4.3-1 libxmu6 2:1.1.0-2 Let me know what else I can do to help track down this problem. Thanks A -- WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 26 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 26, 0, 0, 0, 0, 0, 0, 0, 1440 _NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY _WIN_HINTS(CARDINAL) = 1 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0xe1 _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 14680069 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xe4 WM_CLIENT_LEADER(WINDOW): window id # 0xe1 _NET_WM_PID(CARDINAL) = 18044 WM_LOCALE_NAME(STRING) = en_US.UTF-8 WM_CLIENT_MACHINE(STRING) = blinky WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 1440 by 26 program specified maximum size: 1440 by 26 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = panel, trayer WM_ICON_NAME(STRING) = panel _NET_WM_ICON_NAME(UTF8_STRING) = panel WM_NAME(STRING) = panel _NET_WM_NAME(UTF8_STRING) = panel WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 9234816, 0, 2303789616, 874, 4215058 WM_HINTS(WM_HINTS): Client accepts input or input focus: False Initial state is Normal State. window id # of group leader: 0xe1 _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 14680069 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xe4 WM_CLIENT_LEADER(WINDOW): window id # 0xe1 _NET_WM_PID(CARDINAL) = 32073 WM_LOCALE_NAME(STRING) = en_US.UTF-8 WM_CLIENT_MACHINE(STRING) = blinky WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 1440 by 26 program specified maximum size: 1440 by 26 window gravity: NorthWest
Bug#599003: emacs23-common: flymake fails on certain .tex filenames
Package: emacs23-common Version: 23.1+1-5 Severity: normal Tags: patch When using flymake with .tex filenames that include a number just before the .tex extension, flymake fails to find the master file giving the message Flymake:! in the status bar and rendering flymake useless. For example: myfile1.tex will fail where myfile1a.tex will succeeed. I have not tested this with other modes or file extensions, but looking at http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/progmodes/flymake.el?view=markup there is a regex in (defcustom flymake-allowed-file-name-masks...) that appears to apply: ([0-9]+\\.tex\\' flymake-master-tex-init flymake-master-cleanup) when I remove this line from flymake.el, the problem appears solved. I don't know what other ramifications this may have, but it seems to work for me... trivial patch attached, but note this is against rev 1.63 from savannah. not sure if/how it applies to debian source. A -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs23-common depends on: ii dpkg 1.15.7.2 Debian package management system ii emacsen-common1.4.19 Common facilities for all emacsen emacs23-common recommends no packages. Versions of packages emacs23-common suggests: pn emacs23-common-non-dfsg none (no description available) pn emacs23-elnone (no description available) -- no debconf information --- flymake.el 2010-10-03 10:50:42.0 -0700 +++ flymake_org.el 2010-10-03 10:52:45.0 -0700 @@ -278,7 +278,7 @@ (\\.php[345]?\\' flymake-php-init) (\\.h\\' flymake-master-make-header-init flymake-master-cleanup) (\\.java\\' flymake-simple-make-java-init flymake-simple-java-cleanup) -;;([0-9]+\\.tex\\' flymake-master-tex-init flymake-master-cleanup) +([0-9]+\\.tex\\' flymake-master-tex-init flymake-master-cleanup) (\\.tex\\' flymake-simple-tex-init) (\\.idl\\' flymake-simple-make-init) ;; (\\.cpp\\' 1)
Bug#599003: Acknowledgement (emacs23-common: flymake fails on certain .tex filenames)
Oops, here's a patch the right way around... A --- flymake_org.el 2010-10-03 10:52:45.0 -0700 +++ flymake.el 2010-10-03 10:50:42.0 -0700 @@ -278,7 +278,7 @@ (\\.php[345]?\\' flymake-php-init) (\\.h\\' flymake-master-make-header-init flymake-master-cleanup) (\\.java\\' flymake-simple-make-java-init flymake-simple-java-cleanup) -([0-9]+\\.tex\\' flymake-master-tex-init flymake-master-cleanup) +;;([0-9]+\\.tex\\' flymake-master-tex-init flymake-master-cleanup) (\\.tex\\' flymake-simple-tex-init) (\\.idl\\' flymake-simple-make-init) ;; (\\.cpp\\' 1) signature.asc Description: Digital signature
Bug#452162: hmmm... solved but maybe it's still a bug?
On Fri, Jan 04, 2008 at 04:30:42PM +0100, Josselin Mouette wrote: reassign 452162 gnucash thanks Whoops, sorry for replying without reading this additional information. Le dimanche 25 novembre 2007 à 12:14 -0800, Andrew Sackville-West a écrit : I went back to step zero. This problem showed up after a segfault in gnucash. This segfault occurred while printing checks (uses gtkprint). Subsequent instances of gnucash could no longer print checks. Since I had two machines fully-up-to-date. I decided to try a different user on the broken machine. lo and behold, no problem. :( or :) depending on your perspective. Anyway, moving ~/.gconf out of the way solved the problem. Clearly, the segfault corrupted something in ~/.gconf/* resulting in this behavior. There is probably no way to track down the segfault as it happened in an instance of gnucash that may have been up for many days and may have been up across a variety of upgrades... I have a copy of the problematic ~/.gconf available if you would like. This definitely looks like a bug in gnucash, and the copy of the problematic gconf keys will certainly be useful to the gnucash maintainer. I have that available. Well, I have the whole stinking tree available ;) if anyone wants it. The more I think about it, though, and the more I work on gnucash, I suspect this is a fleeting, one-time thing. I strongly suspect that instance of gnucash had been live across at least a couple significant updates in sid, which brought it to its knees. I don't think any app could be expected to gracefully recover from that kind of systemic change. It was an unfortunate side-effect of the crash that corrupted some gconf keys. This should probably be closed as unreproducible, or needinfo, or whatever. Oh and thanks for finally getting to this. I know it was cryptic at best. A signature.asc Description: Digital signature
Bug#452162: hmmm... solved but maybe it's still a bug?
Okay, I've narrowed this down to a problem in .gconf. After playing around with some other machines and upgrading various packages trying to find this, I ended up with another machine fully up-to-date but *without* the problem. I went back to step zero. This problem showed up after a segfault in gnucash. This segfault occurred while printing checks (uses gtkprint). Subsequent instances of gnucash could no longer print checks. Since I had two machines fully-up-to-date. I decided to try a different user on the broken machine. lo and behold, no problem. :( or :) depending on your perspective. Anyway, moving ~/.gconf out of the way solved the problem. Clearly, the segfault corrupted something in ~/.gconf/* resulting in this behavior. There is probably no way to track down the segfault as it happened in an instance of gnucash that may have been up for many days and may have been up across a variety of upgrades... I have a copy of the problematic ~/.gconf available if you would like. Also, the gnumeric problem appears to be completely unrelated. A signature.asc Description: Digital signature
Bug#452162: libgtk2.0-0: gtkPrint blank pages in gnucash and gnumeric
Package: libgtk2.0-0 Version: 2.12.1-3 Severity: important Beginning somewhere around November 19, 2007 some printing has broken and I think its related to gtkPrint. I realise there are lots of printing changes going on in deb right now, but I think the commonality I'm seeing in symptoms points to gtkPrint. Specifically, in gnucash (which uses both gnomeprint and gtkprint) check printing is broken. For each check printed, a blank page is printed. This result is consistent whether printing to a file (pdf or ps) or to an actual printer. Check printing in gnucash uses gtkprint. Meanwhile, report printing, using gnomeprint, functions just fine. I've also tested this on gnucash svn trunk with the same results. In gnumeric, which uses gtkprint, printing is completely broken. It causes an foomatic-rip failed error in cups. There is more to the gnumeric issue, I think. I downgraded out of the ghostscript package into the gs-* packages and the foomatic-rip failure went away, and gnumeric then printed only blank pages. I tried to downgrade libgtk, but that didn't seem to help, which suggests it may be some other dependency involved. But I think it all stems from gtkprint. Please let me know what I can do to help debug this. I'm happy to downgrade packages, or try different packages to help diagnose this. thanks A -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgtk2.0-0 depends on: ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libc6 2.6.1-6GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libcomerr21.40.2-1 common error description library ii libcupsys21.3.4-1Common UNIX Printing System(tm) - ii libfontconfig12.5.0-2generic font configuration library ii libglib2.0-0 2.14.3-1 The GLib library of C routines ii libgnutls13 2.0.4-1the GNU TLS library - runtime libr ii libgtk2.0-common 2.12.1-3 Common files for the GTK+ graphica ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libkrb53 1.6.dfsg.3~beta1-2 MIT Kerberos runtime libraries ii libpango1.0-0 1.18.3-1 Layout and rendering of internatio ii libpng12-01.2.15~beta5-3 PNG library - runtime ii libtiff4 3.8.2-7Tag Image File Format (TIFF) libra ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcomposite11:0.3.2-1+b1 X11 Composite extension library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxdamage1 1:1.1.1-3 X11 damaged region extension libra ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxfixes31:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxi62:1.1.3-1 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxrandr22:1.2.2-1 X11 RandR extension library ii libxrender1 1:0.9.4-1 X Rendering Extension client libra ii zlib1g1:1.2.3.3.dfsg-7 compression library - runtime Versions of packages libgtk2.0-0 recommends: ii hicolor-icon-theme0.10-1 default fallback theme for FreeDes ii libgtk2.0-bin 2.12.1-3 The programs for the GTK+ graphica -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452162: further info
I've also downgraded all of cups from 1.3.4-1 to 1.3.2-1 with no improvement. That's the only printing dep I could see for gtk. A signature.asc Description: Digital signature
Bug#447211: at76c503a-source: fails to build against 2.6.22-2-686
On Sat, Oct 20, 2007 at 12:06:00PM -0500, kev wrote: i´m experiencing the same problem as reported in Bug #447211: at76c503a-source: fails to build against 2.6.22-2-k7 i have attached the module assistant buildlog plus cpu info. cpu is celeron D. i´m using debian/lenny. thanks 1) you can build from upstream outside of m-a with no problems check out http://at76c503a.berlios.de 2) maintainer says new version (0.17) should be out soon since I've confirmed it can be built unpatched within m-a by tweaking Makefile. A signature.asc Description: Digital signature
Bug#447211: at76c503a-source: fails to build against 2.6.22-2-k7
On Fri, Oct 19, 2007 at 07:53:05AM +0200, Guido Guenther wrote: On Thu, Oct 18, 2007 at 05:48:41PM -0700, Andrew Sackville-West wrote: Package: at76c503a-source Version: 0.15~dev0.20070427-2 Severity: important The package needs an update to 0.17 badly - patches welcome. I'm happy to attempt this. Ill see what I can figure out and get back to you. A signature.asc Description: Digital signature
Bug#447211: at76c503a-source: fails to build against 2.6.22-2-k7
Package: at76c503a-source Version: 0.15~dev0.20070427-2 Severity: important I've tried to build this against linux-image 2.6.22-2-k7 using module-assistant and it fails: output of `m-a a-i at76c503a` dh_clean /usr/bin/make INSTALL_MOD_PATH=/usr/src/modules/at76c503a/debian/at76c503a-modules-2.6.22-2-k7 KVERS=2.6.22-2-k7 KSRC=/lib/modules/2.6.22-2-k7/build clean make[1]: Entering directory `/usr/src/modules/at76c503a' rm -f core *.o *~ a.out *.d rm -f *.ko *.mod.c .*.cmd rm -f *.s *.i rm -rf .tmp_versions make[1]: Leaving directory `/usr/src/modules/at76c503a' rm -f configure-stamp rm -f build-stamp /usr/bin/make -f debian/rules binary-modules make[1]: Entering directory `/usr/src/modules/at76c503a' dh_clean /usr/bin/make INSTALL_MOD_PATH=/usr/src/modules/at76c503a/debian/at76c503a-modules-2.6.22-2-k7 KVERS=2.6.22-2-k7 KSRC=/lib/modules/2.6.22-2-k7/build clean make[2]: Entering directory `/usr/src/modules/at76c503a' rm -f core *.o *~ a.out *.d rm -f *.ko *.mod.c .*.cmd rm -f *.s *.i rm -rf .tmp_versions make[2]: Leaving directory `/usr/src/modules/at76c503a' rm -f configure-stamp rm -f build-stamp if [ -f /usr/src/modules/at76c503a/debian/control ]; then \ cp debian/control.template /usr/src/modules/at76c503a/debian/control; \ fi touch configure-stamp /usr/bin/make INSTALL_MOD_PATH=/usr/src/modules/at76c503a/debian/at76c503a-modules-2.6.22-2-k7 KVERS=2.6.22-2-k7 KSRC=/lib/modules/2.6.22-2-k7/build make[2]: Entering directory `/usr/src/modules/at76c503a' /usr/bin/make -C /lib/modules/2.6.22-2-k7/build M=/usr/src/modules/at76c503a KERNELRELEASE=2.6.22-2-k7 modules make[3]: Entering directory `/usr/src/linux-headers-2.6.22-2-k7' CC [M] /usr/src/modules/at76c503a/at76_usb.o /usr/src/modules/at76c503a/at76_usb.c: In function ‘at76_ieee80211_to_eth’: /usr/src/modules/at76c503a/at76_usb.c:3379: error: ‘struct sk_buff’ has no member named ‘mac’ /usr/src/modules/at76c503a/at76_usb.c: In function ‘at76_ieee80211_fixup’: /usr/src/modules/at76c503a/at76_usb.c:3430: error: ‘struct sk_buff’ has no member named ‘mac’ /usr/src/modules/at76c503a/at76_usb.c: In function ‘at76_rx_monitor_mode’: /usr/src/modules/at76c503a/at76_usb.c:3856: error: ‘struct sk_buff’ has no member named ‘mac’ make[4]: *** [/usr/src/modules/at76c503a/at76_usb.o] Error 1 make[3]: *** [_module_/usr/src/modules/at76c503a] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.22-2-k7' make[2]: *** [modules] Error 2 make[2]: Leaving directory `/usr/src/modules/at76c503a' make[1]: *** [build-stamp] Error 2 make[1]: Leaving directory `/usr/src/modules/at76c503a' make: *** [kdist_image] Error 2 it also fails to build just doing make in the source directory (with the same errors) . Note that version 0.17 from upstream builds properly when built using the typical make sudo make install. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages at76c503a-source depends on: ii atmel-firmware1.3-3 Firmware for Atmel at76c50x wirele ii debhelper 5.0.57 helper programs for debian/rules at76c503a-source recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427447: Workaround for bug!
On Fri, Aug 10, 2007 at 02:46:52AM -0400, Greg Folkert wrote: In all the directories that fc-cache failed with errors like: /usr/share/fonts: failed to write cache /usr/share/fonts/X11: failed to write cache /usr/share/fonts/type1: failed to write cache /usr/local/share/fonts: failed to write cache I went to each directory and ran (as root) mkfontdir ; mkfontscale Only when both were run in each of the problematic directories, did the problem go away, which doesn't explain why its happening. I wonder if this process is just missing from some package? As I reported back to this bug, At some point the error just went away from my aptitude stuff. So I must have inadvertantly installed some other package that fixed it up. Not much help I know, but I'm willing to send my aptitude log is anyoen wants it. A signature.asc Description: Digital signature
Bug#427447: now its gone
Okay, this is wierd. I was continuing to configure this machine on the assumption that the problem would sort itself out... and lo and behold, it did with no apparent reason. I do not recall which of my many aptitude installs did it, but at some point it just stopped showing up as a package to reconfigure... go figure. sorry I can't be of more help, but maybe the aptitude logs would help? If you'd like them, please let me know. A signature.asc Description: Digital signature
Bug#427447: this bug still lives!!!
I have encountered this bug using: delappy:~# dpkg -l fontconfig ... ii fontconfig 2.4.2-1.2 generic font configuration library - support delappy:~# dpkg -l ttf-opensymbol pH ttf-opensymbol 2.2.1-7The OpenSymbol TrueType font delappy:~# dpkg -i /var/cache/apt/archives/ttf-opensymbol_2.2.1-7_all.deb (Reading database ... 84133 files and directories currently installed.) Preparing to replace ttf-opensymbol 2.0.4.dfsg.2-7etch1 (using .../ttf-opensymbol_2.2.1-7_all.deb) ... Unpacking replacement ttf-opensymbol ... Setting up ttf-opensymbol (2.2.1-7) ... Updating fontconfig cache... /usr/share/fonts: failed to write cache /usr/share/fonts/X11: failed to write cache /usr/share/fonts/type1: failed to write cache /usr/local/share/fonts: failed to write cache dpkg: error processing ttf-opensymbol (--install): subprocess post-installation script returned error exit status 4 Errors were encountered while processing: ttf-opensymbol this is on a newly installed system. This error appeared during the lenny system install (business card installer). I left it unresolved and migrated up to sid (where I usually live) and it is still unresolved. I have tried manually purging both packages and reinstalling. If I install ttf-opensymbol first, it will install, but fontconfig will fail. If I install it the other way around, fontconfig fails too. I have attached here the fontconfig.log in case that helps. This is an up-to-date sid system. A /usr/share/fonts: /usr/share/fonts: failed to write cache caching, 0 fonts, 3 dirs /usr/share/fonts/X11: /usr/share/fonts/X11: failed to write cache caching, 0 fonts, 6 dirs /usr/share/fonts/X11/100dpi: caching, 358 fonts, 0 dirs /usr/share/fonts/X11/75dpi: caching, 358 fonts, 0 dirs /usr/share/fonts/X11/Type1: caching, 8 fonts, 0 dirs /usr/share/fonts/X11/encodings: caching, 0 fonts, 1 dirs /usr/share/fonts/X11/encodings/large: caching, 0 fonts, 0 dirs /usr/share/fonts/X11/misc: caching, 55 fonts, 0 dirs /usr/share/fonts/X11/util: caching, 0 fonts, 0 dirs /usr/share/fonts/truetype: caching, 0 fonts, 1 dirs /usr/share/fonts/truetype/ttf-dejavu: caching, 21 fonts, 0 dirs /usr/share/fonts/type1: /usr/share/fonts/type1: failed to write cache caching, 0 fonts, 1 dirs /usr/share/fonts/type1/gsfonts: caching, 35 fonts, 0 dirs /usr/X11R6/lib/X11/fonts: skipping, no such directory /usr/local/share/fonts: /usr/local/share/fonts: failed to write cache caching, 0 fonts, 0 dirs /var/lib/defoma/fontconfig.d: caching, 0 fonts, 5 dirs /var/lib/defoma/fontconfig.d/C: caching, 4 fonts, 0 dirs /var/lib/defoma/fontconfig.d/D: caching, 18 fonts, 0 dirs /var/lib/defoma/fontconfig.d/N: caching, 16 fonts, 0 dirs /var/lib/defoma/fontconfig.d/S: caching, 1 fonts, 0 dirs /var/lib/defoma/fontconfig.d/U: caching, 13 fonts, 0 dirs /var/cache/fontconfig: cleaning cache directory fc-cache: failed signature.asc Description: Digital signature
Bug#434627: status of backport?
I wondered why a hadn't been getting my regular backup emails... This bug explains it. I wonder, what is the status of the backport? My server runs etch and pulls backups from several sid machines which are now no-longer backed up automatically. Is there anything a lowly user can do to help with backporting? living in fear of the disk failure, A signature.asc Description: Digital signature
Bug#433275: mutt: buffy list shows new mail for old
Package: mutt Version: 1.5.16-2 Severity: normal I'm sure this is related to the whole slew of IMAP new mail bugs that have been reported #421468, 428734, and 432148 if not others, but this symptom hasn't been reported, afaict. The buffy list shows all folders with mail marked with New or Old. previously, the buffy list only showed those folders with New mail. This is using up-to-date sid (as of a few days ago) and the server is running etch dovecot imap. A -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mutt depends on: ii libc6 2.5-11GNU C Library: Shared libraries ii libgdbm3 1.8.3-3 GNU dbm database routines (runtime ii libgnutls131.6.3-1 the GNU TLS library - runtime libr ii libidn11 0.6.5-1 GNU libidn library, implementation ii libncursesw5 5.6-3 Shared libraries for terminal hand ii libsasl2-2 2.1.22.dfsg1-8+b1 Authentication abstraction library Versions of packages mutt recommends: ii exim4 4.67-5 meta-package to ease Exim MTA (v4) ii exim4-daemon-light [mail-tran 4.67-5 lightweight Exim MTA (v4) daemon ii locales-all [locales] 2.5-11 GNU C Library: Precompiled locale ii mime-support 3.39-1 MIME files 'mime.types' 'mailcap -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428734: confirm this bug
I can confirm this bug using 1.5.16-2, though mine shows all '0's instead of some other number. also, this is surely a duplicate of #421468. A signature.asc Description: Digital signature
Bug#432585: mdadm: FTR report on raid level synonyms and initramfs hooks
Package: mdadm Version: 2.5.6-9 Severity: normal this problem is documented in: http://lists.debian.org/debian-user/2007/03/msg05310.html http://lists.debian.org/debian-user/2007/04/msg00923.html http://lists.debian.org/debian-user/2007/05/msg01661.html http://lists.debian.org/debian-user/2007/07/msg00856.html with discussion and possible resolution. The problem boils down to a conflict between the manpage descriptions of usage of 'level=' parameters and how they are handled by initramfs hooks. The man pages imply that using various synonyms (eg. level=1 instead of level=raid1) are acceptable, but the initramfs hooks do not properly handle the synonyms resulting in arrays not starting during a boot. There are two sources for determining the MD modules to insert during boot. The first /scripts/local-top/mdadm sets all possible values for MD_MODULES. This is then modified by source /conf/md.conf which includes a new assignment for MD_MODULES based on information gathered from mdadm.conf using /usr/share/initramfs/hooks/mdadm at the time the initrd is built. This hook script does not properly handle all the possible scenarious for level= values in mdadm.conf resulting in erroneous information in /conf/md.conf and MD_MODULES being assigned a garbage value. Ultimately this leads to failed modprobes during the boot and arrays are not properly started. I see two possible resolutions: 1) remove ambiguity in the mdadm and mdadm.conf man pages (less than ideal as the md utilities obviously handle the various synonyms and we'd end up with man pages that do not fully document the available options) or 2) fix up the initramfs/hooks/mdadm script to handle all the synonyms. (preferred in my opinion, as the other md utilities still properly handle the various synonyms) thanks A ps: information below shows running kernel 2.6.18-3-xen-686 but this problem is known to exist in 2.6.18-4 as well. I honestly can't remember why I'm running 2.6.18-3, but i'm quite sure its unrelated to this problem (except that maybe I only fixed the one initrd, can't recall) Shell: /bin/sh linked to /bin/bash -- Package-specific info: --- mount output /dev/md1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/md0 on /boot type ext3 (rw) /dev/mapper/mommadisk-music on /home/andrew/music type ext3 (rw) /dev/mapper/mommadisk-video on /home/andrew/video type ext3 (rw) /dev/mapper/mommadisk-photos on /home/andrew/photos type ext3 (rw) /dev/mapper/mommadisk-backup on /home/backup/backup type ext3 (rw) nfsd on /proc/fs/nfsd type nfsd (rw) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) --- mdadm.conf DEVICE /dev/hd[aceg][1256] /dev/md11 /dev/md12 MAILADDR root ARRAY /dev/md1 level=raid5 num-devices=4 UUID=b7213aca:e6636191:f83021d0:4dfb9941 devices=/dev/hd[aceg]5 ARRAY /dev/md0 level=raid1 num-devices=4 UUID=8c7aacfb:edb6f0ee:fe6d33d7:40b96f38 devices=/dev/hd[aceg]1 ARRAY /dev/md11 level=raid1 num-devices=2 UUID=abc053e7:32092950:8b13dc7d:db065753 devices=/dev/hd[ac]2 ARRAY /dev/md12 level=raid1 num-devices=2 UUID=d0a76b21:c02f7ee7:5eb963fc:fa01d8ad devices=/dev/hd[eg]2 ARRAY /dev/md10 level=raid0 num-devices=2 UUID=3cd26907:67ab0336:62bebf19:fd833d2b devices=/dev/md1[12] ARRAY /dev/md2 level=raid5 num-devices=4 UUID=2f322698:75bf8431:69ddde7a:1129b942 devices=/dev/hd[aceg]6 --- /proc/mdstat: Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] md2 : active raid5 hdg6[0] hde6[3] hdc6[2] hda6[1] 452719296 blocks level 5, 64k chunk, algorithm 2 [4/4] [] md10 : active raid0 md11[0] md12[1] 497664 blocks 64k chunks md12 : active raid1 hda2[0] hdc2[1] 248896 blocks [2/2] [UU] md11 : active raid1 hde2[0] hdg2[1] 248896 blocks [2/2] [UU] md0 : active raid1 hda1[0] hde1[3] hdg1[2] hdc1[1] 248896 blocks [4/4] [] md1 : active raid5 hde5[0] hdc5[3] hda5[2] hdg5[1] 14650944 blocks level 5, 64k chunk, algorithm 2 [4/4] [] unused devices: none --- /proc/partitions: major minor #blocks name 3 0 156290904 hda 3 1 249007 hda1 3 2 249007 hda2 3 3 1 hda3 3 54883728 hda5 3 6 150906546 hda6 22 0 156290904 hdc 22 1 249007 hdc1 22 2 249007 hdc2 22 3 1 hdc3 22 54883728 hdc5 22 6 150906546 hdc6 33 0 156290904 hde 33 1 249007 hde1 33 2 249007 hde2 33 3 1 hde3 33 54883728 hde5 33 6 150906546 hde6 34 0 156290904 hdg 34 1 249007 hdg1 34 2 249007 hdg2 34 3
Bug#431655: xorg restarts when playing video
On Wed, Jul 04, 2007 at 02:32:36AM -0400, Carl Fink wrote: Package: xorg Version: 1:7.2-5 Severity: important woah. fixed already! A signature.asc Description: Digital signature
Bug#431655: xorg restarts when playing video
On Wed, Jul 04, 2007 at 02:32:36AM -0400, Carl Fink wrote: Package: xorg Version: 1:7.2-5 Severity: important hey, nicely done bug report. I'll jump over and add my .02 A signature.asc Description: Digital signature
Bug#431655: sorry!
sorry for the noise! I didn't check my headers before sending . Those were intended for Carl only... regardless: thanks! you guys are fantastic! and sorry again for the noise. A signature.asc Description: Digital signature
Bug#408265: followup on test file
just for the record. the test file above, which crashes oocalc 2.2 reliably on my machine, but not 2.0 on etch, will also cause a crash is saved in oocalc 1.x format, but if saved to .xls (95) and then resaved as .ods works fine, so something is being translated and fixed there. again, hth. A signature.asc Description: Digital signature
Bug#408265: followup on test file
On Thu, Apr 19, 2007 at 02:22:37PM -0500, Ron Johnson wrote: On 04/19/07 13:17, Andrew Sackville-West wrote: just for the record. the test file above, which crashes oocalc 2.2 reliably on my machine, but not 2.0 on etch, will also cause a crash is saved in oocalc 1.x format, but if saved to .xls (95) and then resaved as .ods works fine, so something is being translated and fixed there. again, hth. I just downloaded and opened payroll2007clean.ods using (experimental) OOo 2.2.0-1 without it crashing. Then I upgraded to 2.2.0-4 in unstable. Still no crash. hmmm... what can I do to get more info about what is happening here? my strace I think didn't show any real insight. I'll try from another account. maybe that is the common factor. A signature.asc Description: Digital signature
Bug#408265: followup on test file
On Thu, Apr 19, 2007 at 02:22:37PM -0500, Ron Johnson wrote: I just downloaded and opened payroll2007clean.ods using (experimental) OOo 2.2.0-1 without it crashing. Then I upgraded to 2.2.0-4 in unstable. Still no crash. well, I just tried this on another sid box using versions 2.0.4.dfsg.2-7 and 2.2.0-4 and it works fine on both. Obviously something else is going on on my system. I'll have to mess with cleaning up my configs. FTR, the crashing system has run Oo.o since 1.x whereas the working system has only had 2.0.4 and better. I guess this needs to remain unreproducible. A signature.asc Description: Digital signature
Bug#408265: openoffice.org-calc: confirm similar bug
Package: openoffice.org-calc Version: 2.2.0-4 Followup-For: Bug #408265 I am seeing this behavior as well, but not with all oocalc spreadsheets. It is happening in my payroll spreadsheets. Problem first appeared about 20 days ago or so on my sid system. Does not happen in etch with the same files! In fact a file that opens, edits and saves in etch just fine will not work in sid version even after the successful etch session (I guess that rules out some sort of Save bug in sid version). As I said, this does not appear with all oocalc files, just my payroll ones which use cell naming, multiple cross-linked pages etc. Of note, these files generate an error but do open with gnumeric: W2!F18 : Unable to parse 'oooc:=#REF!.$B$7' because 'Invalid expression' which at least points to a potential location for a problem in the file. I have captured an strace, which I will attach. Also, the error message doesn't actually appear in the terminal or strace until *after* the crash/recovery dialog/and finally quit. I can provide a data file that causes the crash, but give me a couple days as I must obfuscate personal information of my employees first... A -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openoffice.org-calc depends on: ii libc6 2.5-2 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libstlport5.1 5.1.2-1STLport C++ class library ii libufsparse 1.2-7 collection of libraries for comput ii lp-solve 5.5.0.10-3 Solve (mixed integer) linear progr ii openoffice.org-core 2.2.0-4OpenOffice.org office suite archit openoffice.org-calc recommends no packages. Versions of packages openoffice.org-core depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii fontconfig 2.4.2-1.2generic font configuration library ii libaudio2 1.8-4The Network Audio System (NAS). (s ii libc6 2.5-2GNU C Library: Shared libraries ii libcairo2 1.4.4-1 The Cairo 2D vector graphics libra ii libcurl37.15.5-1 Multi-protocol file transfer libra ii libdb4.44.4.20-8 Berkeley v4.4 Database Libraries [ ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.2.1-5 FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-21 GCC support library ii libglib2.0-02.12.11-3The GLib library of C routines ii libgstreamer-plugins-ba 0.10.12-2GStreamer libraries from the base ii libgstreamer0.10-0 0.10.12-3Core GStreamer libraries and eleme ii libgtk2.0-0 2.10.11-2The GTK+ graphical user interface ii libhunspell-1.1-0 1.1.5-6 spell checker and morphological an ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libicu363.6-2International Components for Unico ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libldap22.1.30-13.4 OpenLDAP libraries ii libneon25 0.25.5.dfsg-6An HTTP and WebDAV client library ii libnss3-0d 3.11.5-3 Network Security Service libraries ii libpam0g0.79-4 Pluggable Authentication Modules l ii libpango1.0-0 1.16.2-1 Layout and rendering of internatio ii libpaper1 1.1.21 Library for handling paper charact ii libportaudio2 19+svn20070125-1 Portable audio I/O - shared librar ii libsm6 1:1.0.2-2X11 Session Management library ii libsndfile1 1.0.17-1 Library for reading/writing audio ii libstartup-notification 0.9-1library for program launch feedbac ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libstlport5.1 5.1.2-1 STLport C++ class library ii libx11-62:1.0.3-7X11 client-side library ii libxau6 1:1.0.3-2X11 authorisation library ii libxaw7 1:1.0.3-3X11 Athena Widget library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes'
Bug#394301: confirm this bug
I can confirm this bug and that the patch: rm'ing the *.bak's in the
${LIVE_CHROOT}/boot works.
[EMAIL PROTECTED]:~$ apt-cache policy live-package
live-package:
Installed: 0.99.14-1
Candidate: 0.99.14-1
Version table:
*** 0.99.14-1 0
990 http://debian.midco.net unstable/main Packages
990 http://ftp.us.debian.org unstable/main Packages
100 /var/lib/dpkg/status
also 404314 is a duplicate of this bug.
A
signature.asc
Description: Digital signature
Bug#404153: libmysql-java: out-of-date package causes problems with mysql5
Package: libmysql-java Version: 3.1.11-1 Severity: important I am receiving unknown type '246 in column... error when using mysql 5 tables in openoffice.org base. this is a known issue over at mysql. you can read about it at http://bugs.mysql.com/bug.php?id=14609 this bug was fixed in 3.1.13 of the upstream package and was in the nightly builds as of January 2006. upstream already has 3.1.14 out as well. this bug makes the package unusable for me as I am using the dec type fields in mysql. I could change them to floats, but that seems silly as they aren't... an upgrade would be truly appreciated. ftr, [EMAIL PROTECTED]:~$ mysql -V mysql Ver 14.12 Distrib 5.0.30, for pc-linux-gnu (i486) using readline 5.2 thanks! A -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libmysql-java depends on: ii gij [java2-runtime] 4:4.1.1-13 The GNU Java bytecode interpreter ii gij-4.1 [java1-runtime] 4.1.1-20 The GNU Java bytecode interpreter libmysql-java recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403998: sorry for the noise
I mis-read the bug reports. I'm sorry for the extra noise. A signature.asc Description: Digital signature
Bug#403998: gzip: confirm 1.3.9 uninstallable
Package: gzip Version: 1.3.9-1 Followup-For: Bug #403998 I can confirm this bug. despite what packages.debian.org says, version 1.3.9-1 is coming down the pipe at debian.midco.net. Interestingly though, apt-cache policy shows version 1.3.9-1 already installed. menawhile aptitude is trying to install it, though it is NOT showing up in the list of packages to upgrade. there is something fishy going on here. regardless, my messages are the same as above whether using aptitude or dpkg -i. This of course borks all install processes... A -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages gzip depends on: ii debianutils 2.17.4 Miscellaneous utilities specific t ii libc62.3.6.ds1-9 GNU C Library: Shared libraries gzip recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397083: openoffice.org-calc: OOCalc freezes while printing
Package: openoffice.org-calc Version: 2.0.4-5 Severity: important this occured some months ago with an older 2.0.x version, but quickly disappeared in a regular upgrade. It is now back with a vengeance in the current version. Printing from calc maximises CPU usage (confirmed with top) for about 45 seconds while printing. This renders calc unusable during this time and can hamper the performance of the rest of the system. This happens every time like this: open my spreadsheet (approx 290k, about 25 sheets, though each sheet is not overly complicated). select area to print click the print button on toolbar click the button for printing only selection (though I think it is a problem with any print) calc freezes up for about 45 seconds here is a snip of top showing soffice.bin tying it all up while printing. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 10745 andrew25 0 308m 70m 32m R 99.4 15.9 6:17.17 soffice.bin 6393 root 15 0 226m 30m 9700 S 0.3 7.0 8:05.09 Xorg 11186 andrew15 0 6568 2872 1896 S 0.3 0.6 0:00.13 aterm 1 root 15 0 1944 636 544 S 0.0 0.1 0:01.12 init 2 root RT 0 000 S 0.0 0.0 0:00.00 migration/0 when soffice.bin calms back down (about 45 seconds later), cups spits it right out. I know this isn't much to go on. I'm happy to provide whatever details you might need including a test file, though it does not matter which file I use except that smaller files, with a similarly sized selection SEEM to print faster. A -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages openoffice.org-calc depends on: ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-19 GCC support library ii libstdc++6 4.1.1-19The GNU Standard C++ Library v3 ii libstlport4.6c2 4.6.2-3 STLport C++ class library ii libufsparse 1.2-7 collection of libraries for comput ii openoffice.org-core 2.0.4-5 OpenOffice.org office suite archit openoffice.org-calc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381051: dependency bug
I can confirm this bug and that it affects many other packages. In my case, I failed to install both qemu and mplayer (from marillat repositories) due to nonexisting libdirectfb-0.9-24. How can I tell apt-get or aptitude to ignore this particular requirement? A signature.asc Description: Digital signature
Bug#381051: quick workaround
FTR, libdirectfb-0.9-24 is in testing, so I've added that to my sources list which seems to satisfy aptitude. A signature.asc Description: Digital signature
Bug#343662: fsck errors halting boot after upgrade
Theodore Ts'o wrote: Are you using your system with hardware time set to some non-GMT local time zone? (i.e. /etc/defaults/rcS has UTC=no) you are, of course, correct. And its interesting in that I had set it to UTC at some point and I remember having trouble with my timezones and so forth (my clock in KDE kept getting munched) but the problem went away. h... I think you can make the problem go away by making /etc/localtime contain a copy of what it is currently symlinked to in /usr/share/zoneinfo/timezone, and renaming /etc/rcS.d/S22hwclockfirst.sh to /etc/rcS.d/S09hwclockfirst.sh. This is obviously not the proper fix; since among other things if the localtime file needs to get updated (for example if the US Congress changes the definition of daylight savings time), we need a way to make sure /etc/localtime gets updated when the package gets updated. But I believe if you were to apply the above as a workaround, it should address your problem. Fixing this in the more global sense will require making changes in the overall Debian boot setup, and I'm going to have to take this up on debain-devel and consult other Debian developers. Well, I'm all for doing things the right way and will fix my clock and then unpin apt for e2fsprogs and move back up to 1.39. Thanks for your attention to this matter, and I hope my info will help to continue improvement of Debian for all ;) A Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343042: linux-image-2.6.14-2-686: Boot aborts with message, '/bin/cat: /sys/block/hda/hda1/dev: No such file or directory'
I can confirm, as others have mentioned, that this bug affects AMD systems as well. All of my symptoms were identical to others reported. I chose to downgrade yaird to testing and this resolved the problem (now running 2.6.14-5). I appears to me that the patch mentioned above doesn't apply yet to AMD so I chose this route. I encountered another problem at the same time and I'm trying to determine if they are related. If anyone else encountered this as well, please let me know. All boots now (whether 2.8.14, or 2.6.12 my old kernel) fail with fsck errors on every partition(!). something along the lines of: UNEXEPCTED DISCREPANCY: SuperBlock last write time is in the future. I realise this is likely not related to this bug (especially because it was all part of a massive apt-get upgrade), but since this bug involved ide issues I thought it might apply. any help appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343662: fsck errors halting boot after upgrade
Package: e2fsprogs Version: 1.39 This is specifically version 1.39 WIP (10-Dec-2005) $uname -a Linux basement 2.6.14-2-686 #2 Fri Dec 9 10:11:34 UTC 2005 i686 GNU/Linux $e2fsck -V e2fsck 1.39-WIP (10-Dec-2005) Using EXT2FS Library version 1.39-WIP, 10-Dec-2005 after upgrading kernel and many many packages, reboot gives the following problem: fsck reports error on drives, mounts root with : EXT3-fs warning: mounting fs with errors, running e2fsck is recommended when boot process tries to mount remaining partitions I get: /dev/hda3: Superblock last mount time is in the future /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY I get identical messages for all partitions on two disks except /dev/hda1 which mounts on /boot and /dev/hdb1 and hdb3 which don't mount at boot time (and seem to mount fine later). these errors halt the boot and drop to a shell with the recommendation to manually run fsck or type ctrl-D to continue. either choice, the boot finished fine and system operates fine. so when I manually fsck all the available partitions, it fixes them and marks them as clean. reboot -- same problem happens again. to help diagnose, I booted into knoppix and fsck'd all my partitions from there, then rebooted BACK into knoppix and checked them again (trying to rule out hardware issues) and there were no problems. I mounted a couple of partitions in knoppix just to make sure. all fine. reboot back into Debian and it happens again just as before. this problem also occurs when using kernel 2.6.12 in debian with same e2fsprogs. FWIW, knoppix uses e2fsck 1.38 (30-Jun-2005) and kernel 2.6.12 thanks Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343662: fsck errors halting boot after upgrade
repeated testing with knoppix and a little help from debian-user has resulted in downgrading to 1.38-2 and it now works fine. the downgrade only changes two packages: e2fsprogs and e2fslibs so I think its a strong case that version 1.38-2-1.39-WIP is the source of this problem. ah well. that'll teach me to reboot eh? goodbye sweet sweet uptime (4 months + ). A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
