Bug#750711: Additional information and a better fix
Hello, I have discovered some additional information about what is causing this issue and have found a better fix that requires less editing. I don't know how I missed it the first time, but there is a local config file at $HOME/.byobu/datetime.tmux which contains the following two lines: BYOBU_DATE=%Y-%m-%d BYOBU_TIME=%H:%M:%S This two variables control the status line output when using tmux under Byobu. This file can be used to alter the format of the output or turn it off. Modifying this file does not alter how Byobu fails to honor the date/time status notification settings, so it seems like this might still be part of a workaround. At the very least, I haven't found it documented or mentioned in the changelog. A better (temporary) fix: It is no longer necessary to modify the $HOME/.byobu/profile.tmux file and you do not need to create a profile.tmux.local file to override settings in the system byobu/tmux profile. Instead, simply edit the datetime.tmux file and change the variables to suit. If you want to disable the date, time, or both, commenting the corresponding line does *NOT* work. It's still getting a default value. To disable, set that variable to the empty string. Not wanting the date displayaed, my file looks like: BYOBU_DATE= BYOBU_TIME=%H:%M:%S -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760431: byobu prevents inverted text from displaying and shows as italics instead
Hello Alex, I have narrowed down the source of the text display problems somewhat. I was experimenting with using powerline with tmux. In order to do this, I needed to fully exit byobu/tmux so I could run a plain tmux session. When I did this, I found that the inverted text problem was still present. I take this to mean that it is, in fact, tmux causing these terminal issues and not anything that byobu has added on to it or altered in its configuration. Hope that helps a little. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#750711: byobu always displays date/time regardless of settings
Package: byobu Version: 5.77-1 Followup-For: Bug #750711 Dear Maintainer, I have found the source of this problem, but have only a partial solution. In the file /usr/share/byobu/profiles/tmux see the third line from the end. It looks like this: set -g status-right '#(byobu-status tmux_right)'$BYOBU_DATE$BYOBU_TIME The byobu-status command creates a status line string from the configured status notification plugins. The two variables appended to the line are what is causing the date and time to always be displayed. There seem to be two closely related bugs appearing here. The first is the time and date always being displayed, caused by the two variables above. The second is that byobu-status is not honoring the 'date' and 'time' plugins in the status notification list. If you remove the two variables above, the time and date will no longer be displayed. However, regardless of how you configure byobu's status notifications, you canot get the time and date to show. It seems these two variables are a workaround for this. It could also be that this is some left over debugging cruft from the developer; perhaps a halfway point in fixing the true bug. My half-fix: You could edit the distributed /usr/share/byobu/profiles/tmux file, but the following will fix the problem in your local configuration. The file $HOME/.byobu/profile.tmux looks like: source $BYOBU_PREFIX/share/byobu/profiles/tmux Append the following line to that file: source $HOME/.byobu/profile.tmux.local Edit this new file and add the following line: set -g status-right '#(byobu-status tmux_right)'$BYOBU_TIME Modify this line to your preferred configuration. I only wanted the time displayed and not the date, so I removed the variable that shows the current date. Now restart byobu. This new file overrides the system default for tmux's status-right variable and, temporarily at least, fixes the problem. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 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 byobu depends on: ii cdebconf [debconf-2.0] 0.191 ii debconf [debconf-2.0] 1.5.53 ii gawk1:4.1.1+dfsg-1 ii gettext-base0.19.2-1 ii python 2.7.8-1 ii python-newt 0.52.17-1 ii screen 4.2.1-2 ii tmux1.9-6 Versions of packages byobu recommends: pn run-one none ii screen 4.2.1-2 ii tmux 1.9-6 Versions of packages byobu suggests: pn apport none ii lsb-release 4.1+Debian13 ii po-debconf 1.0.16+nmu3 pn ttf-ubuntu-font-family none pn update-notifier-common none ii vim 2:7.4.335-1+b1 ii w3m 0.5.3-17 -- debconf information: byobu/launch-by-default: false signature.asc Description: Digital signature
Bug#760431: byobu prevents inverted text from displaying and shows as italics instead
On Thu, Sep 04, 2014 at 12:08:36AM -0400, Alex Chernyakhovsky wrote: Hi John, Could you please provide $TERM inside and outside of byobu? I suspect this is an issue with tmux/screen; if inside byobu it is not screen-256color-bce, could you perhaps try setting it to that before running less? Sincerely, -Alex Hello Alex, I tried as you asked, but unfortunately it did not make any noticeable difference. Running under byobu/tmux: $ echo $TERM screen-256color $ TERM=screen-256color-bce less file.foo output from less is unchanged from before Running under bash without byobu: $ echo $TERM xterm-256color $ less file.foo output from less looks normal Just to try, I did the following under byobu: $ TERM=xterm-256color less file.foo Now the output from less looks proper, but this caused other unintended problems. For example, my home/end keys no longer functioned so I could not easily jump to the beginning/end of the file I was viewing. I'm sure there are likely other consequences to trying this, but this was the first I (quickly) ran across. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#760431: byobu prevents inverted text from displaying and shows as italics instead
Package: byobu Version: 5.77-1 Severity: normal Dear Maintainer, Sometime in the last several weeks (four to eight, I think), many programs run in a shell under byobu no longer correctly display inverted text. Instead, the text is displayed in an italics face. The easiest way to reproduce this is to run 'less' on some file. The status line that less displays at the bottom of the screen (typically showing the file name and the position in the file) is normally displayed in an inverted style. It does not appear to be related to the choice of terminal. If I run the less command in a bash shell spawned by byobu, I get the incorrect display. If I run the same command in another terminal window which is not using byobu then the display is correct. Other than selecting a handful of status notifications, I have not altered the byobu configuration. As per the defaults, it is using tmux as the back-end. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 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 byobu depends on: ii cdebconf [debconf-2.0] 0.191 ii debconf [debconf-2.0] 1.5.53 ii gawk1:4.1.1+dfsg-1 ii gettext-base0.19.2-1 ii python 2.7.8-1 ii python-newt 0.52.17-1 ii screen 4.2.1-2 ii tmux1.9-6 Versions of packages byobu recommends: pn run-one none ii screen 4.2.1-2 ii tmux 1.9-6 Versions of packages byobu suggests: pn apport none ii lsb-release 4.1+Debian13 ii po-debconf 1.0.16+nmu3 pn ttf-ubuntu-font-family none pn update-notifier-common none ii vim 2:7.4.335-1+b1 ii w3m 0.5.3-17 -- debconf information: byobu/launch-by-default: false signature.asc Description: Digital signature
Bug#760022: libpam-tmpdir fails to work properly with systemd and suspend
Package: libpam-tmpdir Version: 0.09 Severity: important Dear Maintainer, I recently switch my Debian/testing system to use systemd for init functionality. Prior to this I had been using libpam-tmpdir for awhile without any problems. After switching to systemd I began having issues when resuming the system from suspend or hibernate. The problem manifested itself by files in the tmpdir going missing after resuming. In my case, I am using byobu and an emacs daemon, each of which creates a socket in its respective tmp directory. Upon resuming from suspend/hibernate these tmp files are no longer present. The processes aren't killed, but their utilities can no longer communicate with them. Given the complexity of systemd, I'm not sure where the conflict arises. Considering how frequently systemd seems to create and tear down sessions, that seems a likely area for problems. I think the only PAM module that touches tmp-anything is libpam-tmpdir, so my best guess is that at some point, pre-suspend, systemd removes the user session triggering libpam-tmpdir to remove the user tmpdir and anything in it. When the system resumes, systemd creates a new session and libpam-tmpdir creates a new per-user tmpdir, but it is, of course, now empty. This is just a guess though. Whatever systemd is doing isn't *completely* removing the user session since existing user processes are not killed. Perhaps it has something to do with the addition of cgroups that systemd provices? I'm not sure. If I can provide any additional information, please let me know. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 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 libpam-tmpdir depends on: ii libc6 2.19-9 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii multiarch-support 2.19-9 libpam-tmpdir recommends no packages. libpam-tmpdir suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#750711: byobu always displays date/time regardless of settigs
Package: byobu Version: 5.77-1 Severity: normal Dear Maintainer, The current release of byobu always displays the date/time in the lower-right side of the status bar regardless of whether the date or time status notifications are enabled in the byobu setup. I normally do not display the date and with the other notifications that I have enabled there isn't much room left in an 80 column display. In case the configuration files had changed significantly between releases, I deleted the existing .byobu directory and let it generate new files, but this did not change the behavior. Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 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 byobu depends on: ii cdebconf [debconf-2.0] 0.191 ii debconf [debconf-2.0] 1.5.53 ii gawk1:4.1.1+dfsg-1 ii gettext-base0.18.3.2-1 ii python 2.7.6-2 ii python-newt 0.52.15-3+b1 ii screen 4.2.0-2 ii tmux1.9-5 Versions of packages byobu recommends: pn run-one none ii screen 4.2.0-2 ii tmux 1.9-5 Versions of packages byobu suggests: pn apport none ii lsb-release 4.1+Debian12 ii po-debconf 1.0.16+nmu2 pn ttf-ubuntu-font-family none pn update-notifier-common none ii vim 2:7.4.273-2+b1 ii w3m 0.5.3-15 -- debconf information: byobu/launch-by-default: false -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#742311: gkrellm-cpufreq: cpufreq plugin displays only zeros for CPU frequencies
Hello John, On Sat, Mar 22, 2014 at 10:21:03AM +0100, John Paul Adrian Glaubitz wrote: I have also downloaded the source for version 0.6.5 of the plugin and compiled it. That version did not behave any differently that the current Debian/testing version. Where did you get hold of 0.6.5? Upstream just has 0.6.4 on his website [1] and I couldn't find 0.6.5 anywhere on the web. Oops, my mistake. That was a change I made to the 0.6.4 source when looking into the issue. I wanted to make extra sure I knew gkrellm was using my compiled copy of the plugin and the easiest way was to bump the version number and see it reflected in the plugin info tab. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#742311: gkrellm-cpufreq: cpufreq plugin displays only zeros for CPU frequencies
Package: gkrellm-cpufreq Version: 0.6.4-4 Severity: important Dear Maintainer, The cpufreq plugin for gkrellm is displaying only zeros for the CPU frequencies. On this machine there are four cores and I have cpufreq configured to display only (no sliders or governor controls). It displays lines for each core, but each line reads as 0 MHz. I do not believe the issue is related to the kernel version. I have another machine running the same kernel version and also using the amd64 branch of Debian. On that machine, the cpufreq plugin is working properly. The CPU in that machine is a much older dual-core AMD CPU, while the machine this report is coming from is a much newer Intel i5-2467M CPU. I don't know if that makes a difference. I have looked at the code for the cpufreq plugin. Documentation for the kernel's cpufreq functions is scarce, but I did find that the function used to query the current CPU frequency will return 0 in the case of an error. I believe this is why zeros are displayed for all four cores, but I have not been able to determine what that error could be or why it works on one machine and not another. I have also downloaded the source for version 0.6.5 of the plugin and compiled it. That version did not behave any differently that the current Debian/testing version. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 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 gkrellm-cpufreq depends on: ii gkrellm 2.3.5-5 ii libatk1.0-0 2.10.0-2 ii libc62.18-4 ii libcairo21.12.16-2 ii libcpufreq0 008-1 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-0 2.39.90-2 ii libgtk2.0-0 2.24.22-1 ii libpango-1.0-0 1.36.2-2 ii libpangocairo-1.0-0 1.36.2-2 ii libpangoft2-1.0-01.36.2-2 gkrellm-cpufreq recommends no packages. gkrellm-cpufreq suggests no packages. -- no debconf information -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#582137: Bug remains unfixed
I have just updated to version 1.06.95-6 of dc. From the Debian changelog for version 1.06.95-3: * Applied patch from Paul Dwerryhouse. Closes: #472250: please return support for .dcrc file That changelog entry is dated June 22, 2012, almost a year ago. That bug, now closed, appears to be a duplicate of this bug. Unfortunately, despite what the changelog says the .dcrc file is still not read when dc starts. I am now using the bash function workaround that Stephen Gregory posted in message 15 of this bug thread. This works well, so the fact that this bug is still open is not quite as pressing. That said, there should be some clarification. The .dcrc file is no longer mentioned in the man page, yet the changelog indicates that this feature has been added. Is the upstream unwilling to add this feature? A decision should be made one way or the other to minimize confusion and prevent future bug reports. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#705255: closed by Dave Ewart da...@sungate.co.uk (Closing bug, no follow-up from submitter, likely local issue)
Dave, Your message indicates that you are closing the bug due to lack of follow-up on my part. I did not receive any reply (other than the first BTS automated message). The problem still exists on my systems, but I am unsure what additional information would be useful to discover the cause of this issue. My home laptop system primarily operates off Debian/unstable with a number of packages from Debian/experimental thrown in. A solid system that I use at work operates off Debian/testing. Both of these machines exhibit the same errors as described in the initial bug report. I have a third machine running Debian/stable, but due to some persistent network issues I cannot currently access it to see if this problem occurs there, too. I am perfectly willing to accept that through some fault of mine (local hacking, local misconfiguration, using experimental, etc.) something on my system could be causing colordiff to behave this way. That said, the other machine that exhibits this problem is used by several people and is in most respects a rather typical Debian installation. I do not do any development in Perl so I don't think there is anything special about my Perl environment on either machine that could cause colordiff to behave oddly. I don't even have any local CPAN modules. Is there any other information I can provide? -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max On Tue, May 07, 2013 at 05:09:18PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the colordiff package: #705255: colordiff: error messages ouput with default configuration It has been closed by Dave Ewart da...@sungate.co.uk. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Dave Ewart da...@sungate.co.uk by replying to this email. Date: Tue, 7 May 2013 18:04:58 +0100 From: Dave Ewart da...@sungate.co.uk Subject: Closing bug, no follow-up from submitter, likely local issue To: 705255-d...@bugs.debian.org X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Message-ID: 20130507180458.426cfd5a@rockhopper Closing this bug: no follow-up from the submitter: likely a serious local issue in the colordiff setup for the submitter, but not a colordiff bug. Date: Thu, 11 Apr 2013 20:45:58 -0700 From: John Gruenenfelder jo...@as.arizona.edu Subject: colordiff: error messages ouput with default configuration To: Debian Bug Tracking System sub...@bugs.debian.org Message-ID: 20130412034558.ga27...@as.arizona.edu Package: colordiff Version: 1.0.13-1 Severity: normal Dear Maintainer, All of the output from colordiff begins with four error messages regardless of what input I pass to it. For example, here is what I get when running colordiff on my Mutt config: $ colordiff -U3 .muttrc.home .muttrc Invalid colour specification (no) in /etc/colordiffrc Invalid colour specification (diff) in /etc/colordiffrc Invalid colour specification (off) in /etc/colordiffrc Unknown option in /etc/colordiffrc: cvsstuff --- .muttrc.home2013-04-11 19:03:23.794554623 -0700 +++ .muttrc 2013-04-11 19:19:22.108752374 -0700 This is immediately followed by the rest of the properly colorized diff output. These errors/messages do not appear to have an effect on my usage. I am submitting this bug report because these errors occur with the default configuration as shipped with the colordiff Debian package. I first noticed this with version 1.0.10 but it persists with 1.0.13. I do not have a ~/.colordiffrc file and there have been no changes to /etc/colordiffrc. Users may find this particularly confusing since the default /etc/colordiffrc file says in the comments that, among other values, off is a valid color/alias. Actually, looking closer, it appears that colordiff complains about every line in the file except for comments and the following three lines: newtext=blue oldtext=red diffstuff=magenta I find it odd that there is no existing bug report, especially since this problem seems to have existed since at least version 1.0.10. This would suggest the problem is on my PC or with my configuration, but I haven't been able to find anything. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 colordiff depends on: ii perl 5.14.2-20 colordiff recommends no packages. colordiff suggests no packages. -- no debconf information signature.asc
Bug#705525: mailutils: Install a sample config file for mailutils daemons
Package: mailutils Version: 1:2.99.97-3 Severity: wishlist Dear Maintainer, After running into problems using Courier IMAP and a remote Mutt client I decided to try mailutils-imap4d instead. One of the first steps I usually take is to look at the default or sample configuration that is installed along with a particular daemon. Mailutils, as a whole, ships with an extremely small example config in the documentation directory. The mailutils-imap4d package comes with neither a default configuration (in /etc) nor a sample config file. Lacking these, I began reading the info docs, which I'm sure is what the developers were hoping, and found that I could make imap4d output a sample config with --config-help. This is a good starting point, but it lacks the verbosity of a good default/sample configuration file. Hence this wishlist bug. I would like to see some sort of default configuration installed in /etc or a sample configuration somewhere in /usr/share/doc/mailutils*/. Since I am just beginning to use Mailutil's IMAP daemon, I need to go through part of the documentation anyway. I would be willing to create a more general and verbose config for the IMAP daemon. I wanted to check first, though, because if such a thing is not desired or will be rejected for some existing reason then there is no reason for me to make it. Would this be worth creating and, if useful enough, would it be accepted? -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 mailutils depends on: ii exim4-daemon-heavy [mail-transport-agent] 4.80-7 ii guile-1.8-libs 1.8.8+1-8 ii libc6 2.13-38 ii libfribidi00.19.2-3 ii libgcrypt111.5.0-5 ii libgdbm3 1.8.3-11 ii libgmp10 2:5.0.5+dfsg-2 ii libgnutls262.12.20-4 ii libgsasl7 1.8.0-2 ii libldap-2.4-2 2.4.31-1 ii libltdl7 2.4.2-1.1 ii libmailutils4 1:2.99.97-3 ii libmysqlclient18 5.5.30+dfsg-1 ii libncurses55.9-10 ii libpam0g 1.1.3-7.1 ii libpython2.7 2.7.3-6 ii libreadline6 6.2+dfsg-0.1 ii libtinfo5 5.9-10 ii libwrap0 7.6.q-24 ii mailutils-common 1:2.99.97-3 mailutils recommends no packages. Versions of packages mailutils suggests: ii mailutils-doc 1:2.99.97-3 pn mailutils-mh none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705255: colordiff: error messages ouput with default configuration
Package: colordiff Version: 1.0.13-1 Severity: normal Dear Maintainer, All of the output from colordiff begins with four error messages regardless of what input I pass to it. For example, here is what I get when running colordiff on my Mutt config: $ colordiff -U3 .muttrc.home .muttrc Invalid colour specification (no) in /etc/colordiffrc Invalid colour specification (diff) in /etc/colordiffrc Invalid colour specification (off) in /etc/colordiffrc Unknown option in /etc/colordiffrc: cvsstuff --- .muttrc.home2013-04-11 19:03:23.794554623 -0700 +++ .muttrc 2013-04-11 19:19:22.108752374 -0700 This is immediately followed by the rest of the properly colorized diff output. These errors/messages do not appear to have an effect on my usage. I am submitting this bug report because these errors occur with the default configuration as shipped with the colordiff Debian package. I first noticed this with version 1.0.10 but it persists with 1.0.13. I do not have a ~/.colordiffrc file and there have been no changes to /etc/colordiffrc. Users may find this particularly confusing since the default /etc/colordiffrc file says in the comments that, among other values, off is a valid color/alias. Actually, looking closer, it appears that colordiff complains about every line in the file except for comments and the following three lines: newtext=blue oldtext=red diffstuff=magenta I find it odd that there is no existing bug report, especially since this problem seems to have existed since at least version 1.0.10. This would suggest the problem is on my PC or with my configuration, but I haven't been able to find anything. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 colordiff depends on: ii perl 5.14.2-20 colordiff recommends no packages. colordiff suggests no packages. -- no debconf information -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670714: xserver-xorg-video-intel: [i945GME] Screen corruption after using GL programs
Package: xserver-xorg-video-intel Version: 2:2.18.0-2 Severity: normal Dear Maintainer, I am currently running Debian/sid and using version 2:2.18.0-2 of the Intel video driver. The system is an EeePC 1008HA with a 945GME chipset and a display resolution of 1024x600. This is a 32bit machine with an Intel Atom CPU and 2 GB of RAM. I have X configured to use xscreensaver and have the GL hacks installed. When a GL hack runs, the hack itself looks just fine, but upon exiting I will now have severe display corruption in X. I am using gnome-shell (version 3.2.2.1-3) so I know it is also using GL to show most of its display. The corruption takes the form of windows not having the correct contents, showing portions of other windows, some blockiness and flickering. If I activate gnome-shell's hot-corner in the upper-left to get the application list and display of running programs, the corruption on that screen is very heavy. It's hard to read anything and the background is entirely distorted. When this problem occurs there are no new messages in the kernel log nor in the Xorg.0.log file. As far as the kernel and X are concerned, nothing unusual seems to have occurred. The rest of the Xorg log file is just standard auto-detect messages. There are no warnings or errors. I can make the situation slightly better by repeatedly Alt-TABing from window to window. If my terminal window is distorted, for example, I Alt-TAB in a complete cycle back to the terminal window. This redraw doesn't always fix it, but if I do this several times in a row I can get a usable and viewable window back again. Simply clicking on another window to bring it to the foreground does not seem to work as well, but that could just be my limited testing. Switching to the console and back to X does not fix the problem. Logging out of X and logging back in, which causes X to restart, does fix the problem. I don't know why the GL hack itself displays fine but the rest is distorted. Perhaps this could mean that gnome-shell is at fault here and not the Intel video driver? I'm running gnome-shell on other Debian/sid machines, but they are using different Xorg video drivers. Until about two weeks ago, I was using Ubuntu 11.10 on this machine, running whichever versions of gnome-shell and xserver-xorg-video-intel it shipped with. I did not have any display corruption issues with that setup. In the meantime, I have turned off xscreensaver so that the GL hacks won't corrupt the screen. I do not, at present, have any other fullscreen GL or GL-heavy programs installed to see if they also cause gnome-shell/X to flake out. I apoligize for the lack of boilerplate system configuration information. The netbook with the problem is not (yet) configured to send out email so I have run reportbug on another Debian machine. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582137: dc is ignoring the .dcrc file.
Package: dc Version: 1.06.95-2+b1 Followup-For: Bug #582137 This bug was originally filed in March 2011, almost ten months ago. The report also includes a very small patch that appears to solve the issue. Is there any estimate on when this fix might be included in the Debian version of dc? dc is great little tool, but I don't always remember to execute 4 k every time I run it and then wonder why the division I just did returned a whole number result. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.6 (SMP w/8 CPU cores; PREEMPT) 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 dc depends on: ii dpkg 1.16.1.2 ii install-info 4.13a.dfsg.1-8 ii libc6 2.13-24 dc recommends no packages. dc suggests no packages. -- no debconf information -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626973: tomboy: Tomboy cannot synchronise using ssh
Package: tomboy Version: 1.9.3-1 Followup-For: Bug #626973 Hello, This bug still exists in the current versions of Tomboy (those in testing, unstable, and experimental as of November 23, 2011). Here is the error from my tomboy.log file which seems to indicate that the issue is related not to the notes themselves, but rather to the note templates. I have tried manually deleting the New Note Template mentioned in the log in hopes that it might provide some sort of fix, but there was no change. I hope this can help narrow down the cause of the bug because with this problem still present it makes Tomboy very much less useful away from my desktop computer. Contents of ~/.config/tomboy/tomboy.log: - 11/23/2011 1:05:59 AM [INFO]: Initializing Mono.Addins 11/23/2011 1:06:10 AM [ERROR]: Synchronization failed with the following exception: A note with this title already exists: New Note Template at Tomboy.NoteManager.CreateNewNote (System.String title, System.String xml_content, System.String guid) [0x0] in filename unknown:0 at Tomboy.NoteManager.CreateNoteFromTemplate (System.String title, Tomboy.Note template_note, System.String guid) [0x0] in filename unknown:0 at Tomboy.NoteManager.CreateNewNote (System.String title, System.String guid) [0x0] in filename unknown:0 at Tomboy.NoteManager.CreateWithGuid (System.String title, System.String guid) [0x0] in filename unknown:0 at Tomboy.Sync.SyncManager+CreateNoteInMainThreadc__AnonStoreyF.m__32 () [0x0] in filename unknown:0 at Tomboy.GuiUtils+GtkInvokeAndWaitc__AnonStoreyA.m__23 (System.Object , System.EventArgs ) [0x0] in filename unknown:0 - -- -- John Gruenenfelder -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tomboy depends on: ii gconf2 2.32.4-1 ii libatk1.0-02.2.0-2 ii libc6 2.13-21 ii libcairo2 1.10.2-6.1 ii libdbus-glib1.0-cil0.5.0-3 ii libdbus1.0-cil 0.7.0-4 ii libfontconfig1 2.8.0-3 ii libfreetype6 2.4.8-1 ii libgconf2.0-cil2.24.2-1 ii libgdk-pixbuf2.0-0 2.24.0-1 ii libglib2.0-0 2.30.2-4 ii libglib2.0-cil 2.12.10-2 ii libgmime2.4-cil2.4.25-1 ii libgtk2.0-02.24.7-1 ii libgtk2.0-cil 2.12.10-2 ii libgtkspell0 2.0.16-1 ii libice62:1.0.7-2 ii libmono-addins-gui0.2-cil 0.6.2-1 ii libmono-addins0.2-cil 0.6.2-1 ii libmono-cairo2.0-cil 2.6.7-5 ii libmono-corlib2.0-cil 2.6.7-5 ii libmono-posix2.0-cil 2.6.7-5 ii libmono-system2.0-cil 2.6.7-5 ii libpango1.0-0 1.29.4-2 ii libproxy0 0.3.1-4 ii libsm6 2:1.2.0-2 ii libx11-6 2:1.4.4-4 ii mono-runtime 2.6.7-5 tomboy recommends no packages. Versions of packages tomboy suggests: ii evolution 3.0.3-2 ii tasque 0.1.9-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583349: ++ (as in C++) is not well handled by dhelp
Package: dhelp Version: 0.6.18 Severity: normal The ++ characters are not properly handled by dhelp in a couple of places. The first is in the document index. I have The C++ Annotations, a C++ primer, installed. I used dhelp to browse to it, but this failed when my browser attempted to access http://localhost/doc/c++-annotations/html/index.html and could not find the files. This is because ++ is parsed by the browser and the resulting URL looks something like .../c -annotations/... which doesn't exist. The fix is, I suppose, to use the correct HTML element for the + character. The other problem is rather minor, but dsearch, which *does* handle ++ properly, has a string limit which requires the search string to be at least four characters in lengths. This prevents anyone for looking for all C++ documentation on the system. I realize it is on the main index, but the search string length should probably be lowered to three characters. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.34-1-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 dhelp depends on: ii doc-base 0.9.5 utilities to manage online documen ii libcommandline-ruby1.8 0.7.10-10 Ruby library to write command-line ii libdata-page-perl2.02-1 Help when paging through sets of r ii libdb-ruby1.80.6.5-6 Interface to Berkeley DB for Ruby ii libgettext-ruby1.8 2.1.0-2.1 Gettext for ruby1.8 ii libhtml-parser-perl 3.65-1 collection of modules that parse H ii liblocale-gettext-perl 1.05-6 Using libc functions for internati ii libtemplate-perl 2.22-0.1template processing system written ii liburi-perl 1.54-1 module to manipulate and access UR ii perl-modules 5.10.1-12 Core Perl modules ii poppler-utils0.12.4-1PDF utilitites (based on libpopple ii pstotext 1.9-4 Extract text from PostScript and P ii ruby1.8 1.8.7.249-3 Interpreter of object-oriented scr ii swish++ 6.1.5-2 Simple Document Indexing System fo Versions of packages dhelp recommends: ii elinks [www-browser]0.12~pre5-2 advanced text-mode WWW browser ii galeon [www-browser]2.0.7-2.1+b1 GNOME web browser for advanced use ii iceweasel [www-browser] 3.5.9-3 Web browser based on Firefox ii links2 [www-browser]2.2-1+b2 Web browser running in both graphi ii lynx-cur [www-browser] 2.8.8dev.3-3 Text-mode WWW Browser with NLS sup ii w3m [www-browser] 0.5.2-4 WWW browsable pager with excellent Versions of packages dhelp suggests: ii apache2-mpm-prefork [httpd] 2.2.15-5 Apache HTTP Server - traditional n ii catdvi0.14-11+b1 DVI to plain text translator ii html2text 1.3.2a-15 advanced HTML to text converter ii info2www 1.2.2.9-24 Read info files with a WWW browser ii man2html 1.6f-3 browse man pages in your web brows ii w3m 0.5.2-4WWW browsable pager with excellent -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579500: [Pkg-fglrx-devel] Bug#579500: fglrx-driver: GL screensavers spanning two screens display extensive corruption
On Wed, Apr 28, 2010 at 09:50:35PM -0400, Michael Gilbert wrote: On Wed, 28 Apr 2010 21:22:41 -0400 Michael Gilbert wrote: wontfix 579500 thanks On Tue, 27 Apr 2010 21:03:18 -0700 John Gruenenfelder wrote: I have a large desktop (3200x1200) made by spanning two screens, both plugged into my Radeon HD 4850 video card. When xscreensaver launches a GL hack, it can be a small one which will appear on one screen or another, or it may be one which spans both screens. thanks for the report, but there is really nothing we can do since we don't have access to ati's source code. you should contact them directly for support (afterall you did pay them under the expectation that you would be getting a device with the opengl standard correctly implemented). err, on second thought, their problem is supporting standard x features such as xrandr, rather than implementing their own buggy proprietary multimonitor solution. Hello Mike, To be honest, I really didn't expect a fix given that these are the proprietary drivers. My intention was primarily to have the bug listed in the bug database for others to find and to, perhaps, offer a location for discussion about the bug in the off chance that somebody might find a work-around. And if no fix/work-around is pending, at least others will see that it's not just them, but it is a known fault. As for xrandr... no kidding. It took a lot of trial and error and script hacking to get gdm to run xrandr as the last command of its Init phase and have the call to xrandr actually do what I wanted it to do. Even now, it works, but there is some major voodoo involved because if I disable the simple logging in my xrandr executing script, it won't behave properly. Keep the logging turned on and, surprise, it works as expected. Woo... I really hope the radeon and radeonhd drivers pick up the pace sooner than later. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579500: fglrx-driver: GL screensavers spanning two screens display extensive corruption
Package: fglrx-driver Version: 1:10-4~prerelease-1 Severity: normal I have a large desktop (3200x1200) made by spanning two screens, both plugged into my Radeon HD 4850 video card. When xscreensaver launches a GL hack, it can be a small one which will appear on one screen or another, or it may be one which spans both screens. In this latter case, I get extensive corruption on my right (center, primary) screen. About 1/3 of the screen width in from the left there is a vertical band of garbage which blinks rapidly and I can often see bits of pixmaps from previous programs. Also, beginning at that point but running along the bottom, is a horizontal bar of corruption. This crude ASCII picture may help: [ ] [ X a ] [ b ] [ c X ] [ ] [ XXX] It's roughly something like that. The area labeled a in the diagram contains a heavily distorted mirror of the correct graphics being displayed in the b and c areas. I should also note, and I tried to show this in the diagram, that the screens are not of equal size. The left screen is my secondary display and has a resolution of 1280x1024 and my right display has a resolution of 1920x1200. If I were to hazzard a guess as to the cause of the problems, it might be this mismatched screen geometry. I say this because if a GL hack runs separately in the right or left screen with a non-GL hack in the other display, everything is fine. Also, if two separate GL hacks each run in their own screen, it works too. The corruption only occurs when one hack spans both screens. Finally, you will notice a number of Options enabled and disabled in the driver section of my xorg.conf. I have tried numerous combinations of these options being on and off, but so far nothing has changed the output. Please let me know if there is any additional information you need. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- Package-specific info: VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850] DRM and fglrx Informations from dmesg: [0.00] No AGP bridge found [0.374871] Linux agpgart interface v0.103 [ 20.980771] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 21.017448] [fglrx] Maximum main memory to use for locked dma buffers: 3803 MBytes. [ 21.017587] [fglrx] vendor: 1002 device: 9442 count: 1 [ 21.017852] [fglrx] ioport: bar 4, base 0xb000, size: 0x100 [ 21.018020] [fglrx] Kernel PAT support is enabled [ 21.018036] [fglrx] module loaded - fglrx 8.72.11 [Apr 8 2010] with 1 minors [ 45.054120] fglrx_pci :01:00.0: irq 30 for MSI/MSI-X [ 45.054832] [fglrx] Firegl kernel thread PID: 2339 [ 45.055013] [fglrx] IRQ 30 Enabled [ 47.238169] [fglrx] Gart USWC size:1238 M. [ 47.238172] [fglrx] Gart cacheable size:491 M. [ 47.238178] [fglrx] Reserved FB block: Shared offset:0, size:100 [ 47.238181] [fglrx] Reserved FB block: Unshared offset:fc1f000, size:3e1000 [ 47.238183] [fglrx] Reserved FB block: Unshared offset:1fffb000, size:5000 Xorg X server configuration file status: -rw-r--r-- 1 root root 2682 Apr 23 21:29 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section ServerLayout Identifier aticonfig Layout Screen 0 aticonfig-Screen[0]-0 0 0 EndSection Section Files FontPathunix/:7101 # if the local font server has problems, we can fall back on these FontPath/usr/share/fonts/X11/misc 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 # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us
Bug#519664: New python-gobject breaks screenlets
On Fri, Apr 10, 2009 at 06:57:07PM +0200, Julien Lavergne wrote: Hi, Could you test the patch attached on screenlets and see if the bug still appear ? Thanks. Okay, sorry it took so long to get around to it. The good news is that the patch seems to fix everything. Now, I did it in a rather haphazard manner, applying the patch to the already installed screenlets files on my system rather than grabbing the source. But, despite that, they're working (the ones I use, anyway) with the newer python-gobject package. Thanks a bunch. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519664: New python-gobject breaks screenlets
On Tue, Mar 31, 2009 at 09:12:38AM +0200, Julien Lavergne wrote: Le lundi 30 mars 2009 à 19:56 -0700, John Gruenenfelder a écrit : None of these steps helped and all seem to have the same outcome: $ python .screenlets/ClockRingMod/ClockRingModScreenlet.py Segmentation fault $ python /usr/share/screenlets/Clock/ClockScreenlet.py Segmentation fault $ python /usr/share/screenlets/AppMenu/AppMenuScreenlet.py Segmentation fault And after moving my old screnlets config directories out of the way: $ screenlets-manager Segmentation fault How might I make these commands print more useful information, such as where the segfault is occuring or possibly having python print out a stacktrace rather than simply aborting? You can obtain a stacktrace by following the instructions of this pages : http://wiki.python.org/moin/DebuggingWithGdb . Note that you'll need to install some -dbg packages of different python packages (such as python-cairo-dbg). Okay, I've installed some of the debug packages and now have backtraces for two of the screenlets. I've attached the log files containing the gdb output. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max $ gdb python GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu... (gdb) run /usr/share/screenlets/AppMenu/AppMenuScreenlet.py Starting program: /usr/bin/python /usr/share/screenlets/AppMenu/AppMenuScreenlet.py [Thread debugging using libthread_db enabled] [New Thread 0x7f620ca6f6f0 (LWP 20177)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f620ca6f6f0 (LWP 20177)] PyType_IsSubtype (a=0x2e34530, b=0x7f620b9ba240) at ../Objects/typeobject.c:836 836 ../Objects/typeobject.c: No such file or directory. in ../Objects/typeobject.c (gdb) bt #0 PyType_IsSubtype (a=0x2e34530, b=0x7f620b9ba240) at ../Objects/typeobject.c:836 #1 0x7f620b7a5afc in pyg_type_add_interfaces (class=0x2ed40a0, instance_type=48807952, bases=0x2e948c0, new_interfaces=0, parent_interfaces=0x2e80e50, n_parent_interfaces=0) at /tmp/buildd/pygobject-2.16.1/gobject/gobjectmodule.c:1088 #2 0x7f620b7a5df8 in pyg_type_register (class=0x2ed40a0, type_name=value optimized out) at /tmp/buildd/pygobject-2.16.1/gobject/gobjectmodule.c:1237 #3 0x7f620b7a6cc8 in _wrap_pyg_type_register (self=value optimized out, args=value optimized out) at /tmp/buildd/pygobject-2.16.1/gobject/gobjectmodule.c:954 #4 0x004911d5 in PyEval_EvalFrameEx (f=0x29eafd0, throwflag=value optimized out) at ../Python/ceval.c:3612 #5 0x00491ce2 in PyEval_EvalFrameEx (f=0x2944c70, throwflag=value optimized out) at ../Python/ceval.c:3698 #6 0x004924cd in PyEval_EvalCodeEx (co=0x7f620c836558, globals=value optimized out, locals=value optimized out, args=0x7f620c819488, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2875 #7 0x004dc992 in function_call (func=0x2883ed8, arg=0x7f620c819470, kw=0x0) at ../Objects/funcobject.c:517 #8 0x00418843 in PyObject_Call (func=0x2e34530, arg=0x7f620b9ba240, kw=0x79702e) at ../Objects/abstract.c:1861 #9 0x0041f6e8 in instancemethod_call (func=0x2883ed8, arg=0x7f620c819470, kw=0x0) at ../Objects/classobject.c:2519 #10 0x00418843 in PyObject_Call (func=0x2e34530, arg=0x7f620b9ba240, kw=0x79702e) at ../Objects/abstract.c:1861 #11 0x00465f66 in slot_tp_init (self=0x2ed40a0, args=0x2e94960, kwds=0x0) at ../Objects/typeobject.c:4976 #12 0x0046e04b in type_call (type=0x28cb9c0, args=0x2e94960, kwds=0x0) at ../Objects/typeobject.c:436 #13 0x0041e17b in PyObject_CallFunctionObjArgs (callable=0x28cb9c0) at ../Objects/abstract.c:1861 #14 0x0048ed34 in PyEval_EvalFrameEx (f=0x27d8140, throwflag=value optimized out) at ../Python/ceval.c:4134 #15 0x004924cd in PyEval_EvalCodeEx (co=0x7f620c81c120, globals=value optimized out, locals=value optimized out, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2875 #16 0x004926c2 in PyEval_EvalCode (co=0x2e34530, globals=0x7f620b9ba240, locals=0x79702e) at ../Python/ceval.c:514 #17 0x004a725e in PyImport_ExecCodeModuleEx ( name=0x7fff14a886c0 screenlets, co=0x7f620c81c120, pathname=0x7fff14a85540 /var/lib/python-support/python2.5/screenlets/__init__.pyc) at ../Python/import.c:675 #18
Bug#519664: New python-gobject breaks screenlets
On Tue, Mar 31, 2009 at 12:45:14AM +0200, Julien Lavergne wrote: Hi, Thanks for your bug report. I can't reproduce it under Debian unstable or Ubuntu jaunty which have python-gobject 2.16.1 and python-gtk2 2.14.1. Could you please test the following : - try to launch manually a screenlets : (example : python /usr/share/screenlets/AppMenu/AppMenuScreenlet.py ) - remove/backup your configuration (.config/Screenlets and .screenlets) and try to relaunch screenlets-manager and after, manually a screenlets. Thanks. Regards, Julien Lavergne None of these steps helped and all seem to have the same outcome: $ python .screenlets/ClockRingMod/ClockRingModScreenlet.py Segmentation fault $ python /usr/share/screenlets/Clock/ClockScreenlet.py Segmentation fault $ python /usr/share/screenlets/AppMenu/AppMenuScreenlet.py Segmentation fault And after moving my old screnlets config directories out of the way: $ screenlets-manager Segmentation fault How might I make these commands print more useful information, such as where the segfault is occuring or possibly having python print out a stacktrace rather than simply aborting? -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521655: libdrm2: causes ATI fglrx driver to hard lock the system upon starting X
Package: libdrm2 Version: 2.4.5-2 Severity: important The current version of libdrm2 is completely breaks the fglrx driver. Because the machine completely locks up, I cannot tell exactly what occurs during the X startup procedure which triggers the lock because the log file does not get a chance to sync to disk. However, by process of elimination, I have narrowed down the cause to this package. I did an update on March 25 after which X would no longer work. Checking all the packages I had updated that day did not at first reveal anything as I failed to notice libdrm2. Over the next couple of days, I tried kernels 2.6.26, 2.6.28, and 2.6.29 as well as about six different versions of fglrx. I hadn't changed any of those on the 25th, but I couldn't think of a better area of investigation. Unfortunately, nothing helped. Checking the list of updated packages again, I noticed libdrm2 this time. Fetching version 2.3.1-2 from snapshot.debian.net, I installed it and X began to work again. A big relief. So, whatever changed in libdrm2, it affects all fglrx releases going back about one year and also does not seem dependent on the kernel version. The new libdrm2 does not break the OSS ATI drivers, radeon and radeonhd. Unfortunately, my card has a very new RV770 chipset which is not at all supported by X in Sid and only barely functional with X from experimental, so I can't really use those drivers yet. During my many X experiments trying to discover some new information, I would let X run and while it was starting, I kept hitting the Magic SysRq key combo for emergency sync (Alt-SysRq-S) again and again so that after a crash and reboot I might have some log fragments to look at. It worked a little. When X is trying to start the DRM subsystem I get these messages: drmOpenDevice: node name is /dev/dri/card0 drmOpenByBusid: Searching for BusID PCI:1:0:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenByBusid: drmOpenMinor returns -1 repeats for many cardX values drmOpenDevice: node name is /dev/dri/card14 drmOpenByBusid: drmOpenMinor returns -1 (WW) fglrx(0): Failed to open DRM connection (--) fglrx(0): Video RAM: 524288 kByte, Type: GDDR3 (EE) fglrx(0): [FB] Can not get FB MC address range. I don't know if any of those are useful, but that is the only DRM related information from the log. I can attach the whole log if it might be useful. Using libdrm 2.3.1-2, a successful X log looks like: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenByBusid: Searching for BusID PCI:1:0:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenByBusid: drmOpenMinor returns 11 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 (II) AIGLX: Loaded and initialized /usr/lib/dri/fglrx_dri.so (II) GLX: Initialized DRI GL provider for screen 0 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-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/bash Versions of packages libdrm2 depends on: ii libc6 2.9-6 GNU C Library: Shared libraries libdrm2 recommends no packages. libdrm2 suggests no packages. -- no debconf information -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519664: New python-gobject breaks screenlets
Package: screenlets Version: 0.1.2-4 Severity: grave Justification: renders package unusable Upgrading python-gobject from 2.15.4-2 to 2.16.1-1 causes screenlets to stop working entirely. Specifically, it causes python to segfault. Unfortunately, the user gets no indication of what happens and there are no errors output to .xsession-errors. A segfault message is output to the syslog, however. screenlets-manager just runs: python -u /usr/share/screenlets-manager/screenlets-manager.py Adding -v to that gives a lot of extra output, but still no indication of the problem. I only realized that python-gobject was related because it was one of two python packages upgraded before the breakage. screenlets does not directly depend on python-gobject, but it is a dependency of python-gtk2 which screenlets does depend on. I do not know for a fact that this bug is with screenlets and not python-gobject. I did try running other Python programs to see if any of them were broken, but I could only find problems with screenlets. Python is not one of the languages I know or use so my debugging efforts (beyond adding -v) are minor. It could be that a token effort by somebody who actually knows Python could narrow down the real cause quickly. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-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/bash Versions of packages screenlets depends on: ii python2.5.4-2An interactive high-level object-o ii python-dbus 0.83.0-1 simple interprocess messaging syst ii python-gnome2 2.22.3-3 Python bindings for the GNOME desk ii python-gnome2-desktop 2.24.1-1 Python bindings for the GNOME desk ii python-gtk2 2.14.1-1 Python bindings for the GTK+ widge ii python-support0.8.7 automated rebuilding support for P ii python-xdg0.15-1.1 A python library to access freedes Versions of packages screenlets recommends: ii gnome-keyring 2.24.1-2 GNOME keyring services (daemon and ii python-feedparser 4.1-12 Universal Feed Parser for Python ii python-gmenu 2.24.2-2 an implementation of the freedeskt ii python-gnome2-extras 2.19.1-3.1 Extra Python bindings for the GNOM ii python-gtkmozembed2.19.1-3.1 Python bindings for the GtkMozEmbe ii python-imaging1.1.6-3Python Imaging Library Versions of packages screenlets suggests: ii compiz0.7.6-8OpenGL window and compositing mana pn evolution none (no description available) pn gnome-orcanone (no description available) ii metacity 1:2.24.0-2 A lightweight GTK2 based Window Ma pn python-dcop none (no description available) ii tomboy0.12.2-3 desktop note taking program using pn xfconfnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519712: awn-applets-python-core: python-awnlib = 0.3~bzr912 is not available
Package: awn-applets-python-core Version: 0.2.6-4 Severity: normal Hello, I currently have AWN and applets packages 0.2.6 installed and want to try 0.3~bzrXXX versions but not all of the dependencies are available. Specifically, all dependencies for AWN 0.3~bzr489-1 are present, but there is no 0.3~bzr version of awn-applets-c-core or -extras. For awn-applets-python-core and -extras there is a 0.3~bzr912-1 version, but they depend on python-awnlib = 0.3~bzr912 which is not available in unstable or experimental. Only version 0.2.6-4 appears to be available at this time. Will the package dependencies be available and/or resynchronized sometime soon or was the new version of python-awnlib pulled for some reason? Thanks! -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-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/bash Versions of packages awn-applets-python-core depends on: ii avant-window-navigator0.2.6-7A MacOS X like panel for GNOME ii gnome-icon-theme 2.24.0-2 GNOME Desktop icon theme ii python2.5.4-2An interactive high-level object-o ii python-awn0.2.6-7Python bindings for avant-window-n ii python-awnlib 0.2.6-4Python utilities for avant-window- ii python-central0.6.11 register and build utility for Pyt Versions of packages awn-applets-python-core recommends: ii acpi 1.3-1 displays information on ACPI devic ii awn-manager 0.2.6-7A preferences manager for avant-wi ii python-alsaaudio 0.2-1+b1 Alsa bindings for Python ii python-feedparser 4.1-12 Universal Feed Parser for Python ii python-gst0.100.10.14-2 generic media-playing framework (P awn-applets-python-core suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511079: compiz: Does not properly start from Gnome session
Package: compiz Version: 0.7.6-7 Severity: important I begin using Compiz by running compiz --replace and that works well. To continue using it, I save my current session via the Gnome session applet. However, the session file stores references to compiz.real instead of compiz along with all of the command line arguments. Normally this would be okay, since the session file properly includes the --indirect-rendering argument. Unfortunately, without the compiz script setting the LIBGL_ALWAYS_INDIRECT environment variable, compiz will not start when Gnome does. It tries and fails several times until I am left without a window manager. I can then re-run compiz --replace in a terminal window (which was also saved with the session) and get back to a usable desktop. I'm not sure what the solution is since gnome-session has no way of knowing that it should save calls to compiz instead of compiz.real. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.7.6-7OpenGL window and compositing mana ii compiz-gnome 0.7.6-7OpenGL window and compositing mana ii compiz-gtk0.7.6-7OpenGL window and compositing mana ii compiz-plugins0.7.6-7OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.7.6-3Compizconfig Settings Manager -- no debconf information -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484753: linux-image-2.6.24-1-amd64: Fails to boot. Unable to mount root fs
On Mon, Nov 24, 2008 at 11:00:38PM +0100, Moritz Muehlenhoff wrote: On Sun, Jun 29, 2008 at 04:29:38PM +0200, maximilian attems wrote: 2.6.25 from unstable should just install fine, please report the error message you are seeing on boot. please follow those instructions for debug - http://wiki.debian.org/InitramfsDebug Does this error still occur with more recent kernel versions? Seems I forgot to follow up on this report. No, the problem is no longer occuring on newer kernels. Currently, the machine is using 2.6.26-8 and is behaving fine. -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484871: surfraw-update-path breaks tcsh
Package: surfraw
Version: 2.2.1-2
Severity: normal
Running surfraw-update-path -add -sys -all adds lines to /etc/csh.cshrc to
put surfraw's tools into the default PATH. However, the syntax it uses breaks
the PATH for tcsh users and they are unable to run any commands.
Specifically, it inserts:
set path=($PATH /usr/lib/surfraw)
If, instead, the following were used:
setenv PATH=${PATH}:/usr/lib/surfraw
it would accomplish the same thing and does not break tcsh's PATH. I do not
have regular csh installed so I do not know if the original syntax also causes
problems with it.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages surfraw depends on:
ii iceweasel [www-browser] 2.0.0.14-2 lightweight web browser based on M
ii links [www-browser] 2.1pre36-1 Web browser running in text mode
ii lynx [www-browser] 2.8.6-2 Text-mode WWW Browser
ii w3m [www-browser] 0.5.1-5.1+b1 WWW browsable pager with excellent
Versions of packages surfraw recommends:
ii links 2.1pre36-1 Web browser running in text mode
ii surfraw-extra 2.2.1-2 extra surfraw elvi with heavy depe
ii w3m 0.5.1-5.1+b1 WWW browsable pager with excellent
-- no debconf information
--
--John GruenenfelderResearch Assistant, UMass Amherst student
Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://weaselreader.org
This is the most fun I've had without being drenched in the blood
of my enemies!
--Sam of Sam Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459852: fglrx-driver: Driver forces large virtual size
Package: fglrx-driver Version: 8.44.3-1 Severity: grave Justification: renders package unusable I am using a Radeon X300 with a monitor running at 1280x1024. The driver is forcing a virtual size with twice the X dimension even though there is no second display attached. I have attempted a number of things to get around this, but none worked: 1) Set 'Virtual' to 1280 1024 in the Display section of xorg.conf 2) Forcing Xinerama to be disabled 3) Using the fglrx option DesktopSetup to single 4) Specifying a specific modeline and turning off EDID or DDC None of these had any effect. It seems that the driver is just ignoring everything I tell it. And in the case of #4 where I specified a modeline, the X server just crashed at startup. While the driver is scanning through all sorts of modes (I don't know where it gets them) I see at the beginning: (II) fglrx(0): Total of 50 modes found for primary display. (--) fglrx(0): Virtual size is 1280x1024 (pitch 0) (**) fglrx(0): *Mode 1280x1024: 135.0 MHz (scaled from 0.0 MHz), 80.0 kHz, 75.0 Hz (II) fglrx(0): Modeline 1280x1024 135.00 1280 1296 1440 1688 1024 1025 1028 1066 This looks correct. But as the modes keep passing by, I see: (**) fglrx(0): Default mode 320x200: 12.6 MHz (scaled from 0.0 MHz), 31.5 kHz, 60.0 Hz (D) (II) fglrx(0): Modeline 320x200 12.59 320 336 384 400 200 457 459 524 doublescan (--) fglrx(0): Display dimensions: (330, 240) mm (--) fglrx(0): DPI set to (98, 108) (--) fglrx(0): Virtual size is 2560x1024 (pitch 2560) (**) fglrx(0): *Mode 1280x1024: 135.0 MHz (scaled from 0.0 MHz), 80.0 kHz, 75.0 Hz (II) fglrx(0): Modeline 1280x1024 135.00 1280 1296 1440 1688 1024 1025 1028 1066 It then proceeds to run though the same list of modelines three more times. The end result is that the single monitor is indeed running at 1280x1024 @75Hz, but the virtual size is at 2560x1024 and I can't change it. Perhaps this is related to the widescreen resolutions bug? I also tried the previous version, 8.43.2-2, but it did the same thing. I am upgrading from 8.39.4-1. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages fglrx-driver depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1] 7.0.2-3A free implementation of the OpenG ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxrandr22:1.2.2-1 X11 RandR extension library ii libxrender1 1:0.9.4-1 X Rendering Extension client libra ii xserver-xorg 1:7.2-5the X.Org X server Versions of packages fglrx-driver recommends: ii fglrx-kernel-src 8.44.3-1 kernel module source for the non-f -- no debconf information -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365441: xserver-xorg-video-savage: XVideo extension using too much CPU
On Sun, May 06, 2007 at 10:16:25AM +0200, Brice Goglin wrote: The savage driver, at least on this particular chipset, also had a few other issues including some corruption/artifacts with Xvideo playback and instability with GL, so the upgrade was worth it. Does this mean that you won't be able to debug anymore if a new release comes out? In this case, there's no real point to keep this bug open, unless somebody else complains... Thanks, Brice That is correct, I won't be using the driver anymore. When I posted to the Xorg list even though I didn't get any help I did get another user to speak up. I believe we had the same Shuttle box/mobo with the same Savage chipset. He was experiencing similar problems. But, unless he decides to comment on this bug report I don't know how he might be contacted. -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365441: xserver-xorg-video-savage: XVideo extension using too much CPU
On Sat, May 05, 2007 at 01:01:34PM +0200, Brice Goglin wrote: Hi, About a year ago, you reported a bug to the Debian BTS regarding XVideo using too much CPU on a Savage board. Did you reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. Thanks, Brice Hello, It never really went away. That is, even with the latest (as of about one month ago) version in unstable it was still present. I was unable to get any help or pointers on the xorg mailing list so I eventually gave up and bought a cheap Nvidia card. This machine is my MythTV box and Myth has a couple of extra features on Nvidia cards (such as sync on v-blank for TV-out). The savage driver, at least on this particular chipset, also had a few other issues including some corruption/artifacts with Xvideo playback and instability with GL, so the upgrade was worth it. -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385393: xserver-xorg-video-i810: Please include modesetting branch
Package: xserver-xorg-video-i810 Version: 2:1.6.5-2 Severity: wishlist The i810 driver currently has both a main and a modesetting branch. This other branch often works better, on some newer models, than the regular i810 driver. Would it be possible to include both of them in the i810 package? The Fedora rawhide package for the i810 driver includes both, naming the modesetting driver intel to avoid any conflicts. It would help those of us with hardware not fully supported by the current i810 driver. --John Gruenenfelder -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xserver-xorg-video-i810 depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii xserver-xorg-core2:1.1.1-5 X.Org X server -- core server xserver-xorg-video-i810 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385393: xserver-xorg-video-i810: Please include modesetting branch
On Wed, Aug 30, 2006 at 04:14:01PM -0400, David Nusinow wrote: On Wed, Aug 30, 2006 at 07:39:30PM -0400, John Gruenenfelder wrote: Would it be possible to include both of them in the i810 package? The Fedora rawhide package for the i810 driver includes both, naming the modesetting driver intel to avoid any conflicts. It would help those of us with hardware not fully supported by the current i810 driver. So I've actually spoken with one of the Fedora X maintainers about this driver. The driver isn't really cooked yet, which is why it's still on a development branch in upstream git. I've thought about doing unofficial packages for it, and probably will at some point soon (I'd like to play with it myself, being a newly minted intel chip owner), but as for shipping it with Etch, I don't think it's ready currently. If it lands upstream in time, you can bet I'll make the effort to release it though. - David Nusinow Okay, I can see the rational behind that. If you do make any unofficial packages, please let me know. I'd be very eager to test them. Thanks for the quick response. -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365441: xserver-xorg-video-savage: XVideo extension using too much CPU
On Sun, Apr 30, 2006 at 11:40:37AM +0200, Michel Dänzer wrote: On Sat, 2006-04-29 at 23:11 -0400, John Gruenenfelder wrote: Package: xserver-xorg-video-savage Version: 1:2.0.2.3-4 Severity: normal After upgrading to the new modular X packages, I find that my X setup now uses an excessive amount of CPU time to play back video when using the XVideo extension. The machine is my MythTV box. It is a small Shuttle box with builtin S3 Inc. VT8375 [ProSavage8 KM266/KL266] video on the motherboard. With the previous X packages video playback was excellent. The problem appears to affect any program which makes use of the XVideo extension (MythTV, mplayer, xine, etc.). This is most likely a duplicate of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362755 . Sorry for dropping this... I hadn't had any time to fiddle with my Myth box for too long. My problem is, it seems, only tangentially related to that issue. It is true that the MTRR is not set properly, but even after I set it manually the X server is still using far too much CPU. Without MTRR set: 100% CPU needed for software decoding and X server and video skips a lot. With MTRR set: ~40% CPU used just by X server while video plays. That's still far too much. The machine in question has an Athlon XP 2000 CPU. On another slightly faster computer (unfortunately, not the same graphics chipset), while playing the same video file the X server will consume just under 5% of the CPU. So now, between CPU decoding costs and the CPU used by this Xv inefficiency, playing a simple video will take 70-80% of the CPU. This means skipping can (and does) occur from time to time if the computer is tasked with something else in the background. This was not an issue with X 6.9, but it is a problem with 7.0 and newer (still running Debian/Sid). -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max
Bug#381181: mdadm fix affects root-on-LVM-on-RAID
On Mon, Aug 21, 2006 at 11:05:23AM +0100, martin f krafft wrote: also sprach John Gruenenfelder [EMAIL PROTECTED] [2006.08.21.0513 +0100]: So... what is the best fix for this? Is there some fix I'll need to make to my initrd? Or will removing /etc/udev/mdadm.rules be enough to cause udev to go back to the old behavior? Udev now creates them again, it was my mistake to prevent it from doing so. The 2.5.3 upload I made yesterday to unstable (still on http://incoming.debian.org for today) fixes it. I would appreciate if you could test it. Yes, the new package fixes the problem. My system is now booting hands free again. Thank you for the quick response and fix. -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381181: mdadm fix affects root-on-LVM-on-RAID
Hello, I set my system up some time ago to use root on LVM on RAID. Not just root, actually, but all filesystems are on LVM on RAID with the exception of /boot which is just on RAID. With the latest update to mdadm, my system could no longer boot properly. Before I found this bug report, I managed to trace the problem on my own. Now that udev no longer creates the /dev/md* devices, the lvm startup script cannot find my volume groups. Without those I am missing most of my filesystems and cannot boot. As a quick fix, I can boot into single user mode, create /dev/md0 and /dev/md3 (the two which I need), run /etc/init.d/lvm, and then mount my filesystems. At that point I can continue the normal boot process. Now, I roll my own kernel via make-kpkg and the initrd I created on my own to get this setup working, so perhaps there is some Debian specific way of handling this that I am not doing correctly. So... what is the best fix for this? Is there some fix I'll need to make to my initrd? Or will removing /etc/udev/mdadm.rules be enough to cause udev to go back to the old behavior? -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365441: xserver-xorg-video-savage: XVideo extension using too much CPU
On Sun, Apr 30, 2006 at 11:40:37AM +0200, Michel Dänzer wrote: On Sat, 2006-04-29 at 23:11 -0400, John Gruenenfelder wrote: Package: xserver-xorg-video-savage Version: 1:2.0.2.3-4 Severity: normal After upgrading to the new modular X packages, I find that my X setup now uses an excessive amount of CPU time to play back video when using the XVideo extension. The machine is my MythTV box. It is a small Shuttle box with builtin S3 Inc. VT8375 [ProSavage8 KM266/KL266] video on the motherboard. With the previous X packages video playback was excellent. The problem appears to affect any program which makes use of the XVideo extension (MythTV, mplayer, xine, etc.). This is most likely a duplicate of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362755 . It does look very similar. The report mentions being able to temporarily fix this by manually setting the MTRR. If I could do this, I could test this and let you know for certain. Unfortunately, the other bug report does not give any specifics for this. Looking at the mtrr.txt file included with the kernel, I have tried a few things. The current MTRRs are: reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x1e00 ( 480MB), size= 32MB: uncachable, count=1 reg02: base=0xd800 (3456MB), size= 64MB: write-combining, count=1 reg05: base=0xd800 (3456MB), size= 64MB: write-combining, count=1 reg01 is the video framebuffer. Because this is a motherboard video chipset, the video memory is taken from main memory. I am having trouble setting the MTRR to what I believe it should be: foxstar:~# echo base=0x1e00 size=0x200 type=write-combining | /proc/mtrr bash: echo: write error: Invalid argument So I tried getting rid of the existing MTRR settings first: foxstar:~# echo disable=1 | /proc/mtrr foxstar:~# cat /proc/mtrr reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg02: base=0xd800 (3456MB), size= 64MB: write-combining, count=1 reg05: base=0xd800 (3456MB), size= 64MB: write-combining, count=1 foxstar:~# echo base=0x1e00 size=0x200 type=write-combining | /proc/mtrr bash: echo: write error: Invalid argument Am I doing something wrong here? Or perhaps this must be done differently when the video memory is under the same MTRR as the main system memory? -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max
Bug#365441: xserver-xorg-video-savage: XVideo extension using too much CPU
Package: xserver-xorg-video-savage Version: 1:2.0.2.3-4 Severity: normal After upgrading to the new modular X packages, I find that my X setup now uses an excessive amount of CPU time to play back video when using the XVideo extension. The machine is my MythTV box. It is a small Shuttle box with builtin S3 Inc. VT8375 [ProSavage8 KM266/KL266] video on the motherboard. With the previous X packages video playback was excellent. The problem appears to affect any program which makes use of the XVideo extension (MythTV, mplayer, xine, etc.). I have looked through the X log, but I did not see anything out of the ordinary. I also checked the savage man page, but I did not find any new information or anything that might relate to the problem. I will also include my xorg.conf and Xorg.0.log files. -- 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.16 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xserver-xorg-video-savage depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries ii xserver-xorg-core 1:1.0.2-7 X.Org X server -- core server xserver-xorg-video-savage recommends no packages. -- no debconf information # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files 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 # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadtype1 Loadv4l Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ExplorerPS/2 Option Emulate3Buttons true EndSection Section InputDevice Identifier LIRC-Mouse Driver mouse Option Device/dev/lircm Option Protocol IntelliMouse Option SendCoreEvents EndSection Section Device Identifier S3 ProSavage8 Driver savage EndSection Section Monitor Identifier Generic Monitor Option DPMS DisplaySize 203 152 EndSection Section Screen Identifier Default Screen Device S3 ProSavage8 Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice LIRC-Mouse EndSection
Bug#349287: am-utils: amd segfaulting on amd64 (x86_64)
On Mon, Jan 23, 2006 at 09:15:07AM +, Tim Cutts wrote: Thanks for the files. I can't currently see how you're telling amd to use your amd.home map; it's not mentioned in the defaults/am-utils file, and it's commented out in the amd.conf file - did you modify the /etc/init.d/am-utils file directly to do it, and if so, can you tell me what the exact command line is that am-utils is getting launched with? Tim Oh, I should have made that a little more clear. The machine in question is not actually using the amd.home map. The other two machines in the cluster use it. I just included it for completeness. On this particular machine, /home is local so there is no need for a map. But, to insure that some file is accessible on all machines through the same path, we often use things like /net/bach/d1/foo even when on machine bach. That way the path doesn't change if accessed from another machine. The other two machines which use amd.home receive it via NIS. -- --John GruenenfelderResearch Assistant, UMass Amherst student Systems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349287: am-utils: amd segfaulting on amd64 (x86_64)
On Sun, Jan 22, 2006 at 12:28:16PM +, Tim Cutts wrote:
Jan 21 16:26:58 bach kernel: amd[2840]: segfault at
rip 2b1a3890 rsp 7fe93c08 error 4
The not responding/OK messages occur once or twice an hour.
Currently,
the other machines in our small cluster are not being used, so all of
the NFS traffic is local to this machine.
Can you actually reproduce this on demand, or does it just
occasionally fall over? Could add your automount map files to the
bug report, so that I (and the am-utils developers) can see exactly
what the configuration is?
Unfortunately, I can't reproduce this on demand. At least, I haven't
discovered if there is some specific thing that a user can do to trigger it.
It seems to happen more or less at random. As I mentioned above, the not
responding/OK messages occur once or twice and hour. The segfaulting seems to
occur about once every 1-2 days.
Before this machine's hardware was upgraded (it used to be x86) and Debian
reinstalled, the not responding/OK messages occured, but with less
regularity. amd did not segfault, however, and NFS seemed okay, so I just
ignored the messages.
I've seen some reports similar to this on the am-utils mailing list,
so I'll forward your bug report to them and see what they think. But
in the mean time, the full details of your configuration would be
useful, i.e. your amd.conf file, your /etc/default/am-utils file and
any map files referred to by the amd.conf file.
Thanks,
Tim
Can do. I've attached my amd.conf and /etc/default/am-utils files as
well as the amd.home map.
--
--John GruenenfelderResearch Assistant, UMass Amherst student
Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net
This is the most fun I've had without being drenched in the blood
of my enemies!
--Sam of Sam Max
# Sample amd.conf for Debian GNU/Linux
# $Id: amd.conf,v 1.5 2002/03/20 19:16:29 phil Exp $
# For the commented options, the default is shown
[global]
### Global parameters
# Override the achitecture ?
#arch = i386
# Where to mount the filesystems
auto_dir = /amd
# Override the default 300 seconds (5 minutes) cache timeout
#cache_duration = 300
# Set a cluster string ?
#cluster = lab
# Debug ?
#debug_options = all
# Override the default 120 seconds (2 minutes) umount interval
#dismount_interval = 120
# Override the full OS string
#full_os = linux-2.2.18
# Do we want to reference hosts via their FQDN ?
#fully_qualified_hosts = no
# What's the hesiod base name ?
#hesiod_base = automount
# Kernel architecture override
#karch = i386
# LDAP parameters
#ldap_base =
#ldap_cache_maxmem = 131072
#ldap_cache_seconds = 0
#ldap_hostPorts =
# Override the DNS domainname (defaults to the part after the first
# dot of the machine fully qualified domain name (FQDN)
#local_domain = yourdomain.org
# Where to log to...
log_file = syslog
# What to log ?
log_options = all,noinfo,nostats,nomap
# What IP protocol to use when doing NFS ? (tcp or udp)
# If specified here, *all* mounts will use udp, regardless of the map contents
# nfs_proto = udp
# How many retransmissions will the kernel attempt when communicating
# with amd ?
#nfs_restransmit_counter = 11
# Timeout in tenths of second between retransmissions when the kernel
# communicates with amd ?
#nfs_retry_interval = 8
# NFS version to use ? (2 or 3)
# If specified here, *all* mounts will use it, regardless of the map contents
nfs_vers = 3
# NIS domain name to retrieve map from (defaults to the locally bound
# domain)
#nis_domain = your-nis-domain
# Do we want to normalize host names when expanding ${rhost}
#normalize_hostnames = no
# Override the os string ?
#os = linux
# Override the os version ?
#osver = 2.2.18
# Where to print the PID if print_pid is set
#pid_file = /dev/stdout
# Try to lock amd into memory with plock() ?
#plock = yes
# What portmapper program number do we register for communications between
# amd and the various utilities ?
#portmap_program = 300019
# Print our pid on startup ? (not needed, we use amq for that)
#print_pid = no
# Print amd version on startup ?
#print_version = no
# At startup, do we restart existing mounts if we determine they could
# have been automounted ?
restart_mounts = yes
# Do we want to be able to use selectors on the /defaults map entry ?
selectors_in_defaults = yes
# Do we return the number of automount entries on statfs()/df ?
#show_statfs_entries = no
# Do we attempt to unmount all automounted file systems on exit ?
unmount_on_exit = yes
# Override vendor ?
vendor = Debian
### Default parameters, can be overriden on a map-by-map basis
# Do we show unmounted automount points on readdir()
#browsable_dirs = yes
# Default map options
Bug#349287: am-utils: amd segfaulting on amd64 (x86_64)
Package: am-utils Version: 6.1.3-2 Severity: important amd has been exhibiting some nasty problems on an amd64 machine running the x86_64 port of Debian/testing. Specifically, it periodically segfaults and must be manually restarted. The usage of amd on this machine is important, but the machine is currently under a very light load. I see many messages in the log like this: Jan 21 16:07:17 bach kernel: nfs: server [EMAIL PROTECTED]:/net not responding, still trying Jan 21 16:07:18 bach kernel: nfs: server [EMAIL PROTECTED]:/net OK Jan 21 16:07:27 bach kernel: nfs: server [EMAIL PROTECTED]:/net not responding, still trying Jan 21 16:07:27 bach kernel: nfs: server [EMAIL PROTECTED]:/net OK Jan 21 16:26:58 bach kernel: nfs: server [EMAIL PROTECTED]:/net not responding, still trying Jan 21 16:26:58 bach kernel: amd[2840]: segfault at rip 2b1a3890 rsp 7fe93c08 error 4 The not responding/OK messages occur once or twice an hour. Currently, the other machines in our small cluster are not being used, so all of the NFS traffic is local to this machine. This configuration was previously used for quite some time on our old hardware which was x86. On the new amd64 machine this has been run under kernel 2.6.12 and 2.6.15 with similar results. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages am-utils depends on: ii debconf [debconf-2.0] 1.4.67 Debian configuration management sy ii libamu4 6.1.3-2Support library for amd the 4.4BSD ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libhesiod03.0.2-16 Libraries for hesiod, a service na ii libldap2 2.1.30-12 OpenLDAP libraries ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra ii perl 5.8.7-10 Larry Wall's Practical Extraction ii portmap 5-16 The RPC portmapper am-utils recommends no packages. -- debconf information: am-utils/import-amd-failed: am-utils/nis-master-map: amd.master am-utils/config-reimport: import am-utils/nis-key: default * am-utils/done: yes am-utils/map-others: am-utils/nis-master-map-key-style: onekey am-utils/config-md5sum: bf8b03bb9b47986ec8d2dbd8690a85db * am-utils/map-net: true am-utils/config-reimport-failed: am-utils/reconfigure: * am-utils/use-nis: false am-utils/nis-custom: echo /amd-is-misconfigured /usr/share/am-utils/amd.net am-utils/import-amd-conf-done: false am-utils/import-amd-conf: false * am-utils/map-home: false am-utils/log-to-file: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314173: libmpich1.0-dev installs incorrect alternative for /usr/lib/libmpi++.so
Package: libmpich1.0-dev Version: 1.2.5.3-5 Severity: important When installing the package, it creates an incorrect alternatives symlink for libmpi++.so: /usr/lib/libmpi++.so - /etc/alternatives/libmpi++.so /etc/alternatives/libmpi++.so - /usr/lib/mpich/lib/shared/libpmpich.so This is incorrect. The correct symlink should be: /etc/alternatives/libmpi++.so - /usr/lib/mpich/lib/shared/libpmpich++.so This problem only seems to be with this one symlink. The symlink for the static library is correct: /usr/lib/libmpi++.a - /etc/alternatives/libmpi++.a /etc/alternatives/libmpi++.a - /usr/lib/mpich/lib/libpmpich++.a Trying to compile a program with the incorrect link will result in numerous linker errors. --John Gruenenfelder -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libmpich1.0-dev depends on: ii libmpich1.0 1.2.5.3-5 mpich runtime shared library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
