[Bug 875070] Re: gnome terminal intercepts my alt key combinations when it shouldn't
So, the linked gnome bug has this to say: "I found a posted workaround that seams to have fixed the problem: sudo apt-get remove appmenu-gtk3 appmenu-gtk appmenu-qt" followed up with: "Alright, if that makes the bug disappear, it's NOTGNOME. The ubuntu 'global menu' stuff is NOT supported; removing it is the right thing to do!" So... is this going to be a case of both teams pointing at each other, or is there someone that supports the appmenu/gnome-terminal integration that can track this down and definitively determine who needs to fix it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/875070 Title: gnome terminal intercepts my alt key combinations when it shouldn't To manage notifications about this bug go to: https://bugs.launchpad.net/appmenu-gtk/+bug/875070/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 874409] Re: apt-get -q flag fails to squelch status -qq hides everything
Your reply doesn't actually help. This is a clear bug. It's either a docs bug (in which case the documentation should clearly state that progress information, such as while file is being read, cannot be silenced without silencing the entire program); or the program doesn't behave the way the documentation describes. As a user reading those docs, what I'm looking for when I go looking for a "quiet" option is a way to make the program output less verbose. In the above sample output, all most uses of the tool require (and certainly the only relevant output to the request, given that I've requested a quiet execution) is that the package is already installed. Local definitions of what a "progress" message vs. and "error" message are isn't interesting to the user. What's interesting is the result of the command, which as far as I can tell is either the second-to-last line or the last two lines. If you're set in calling only marching progress percentages "progress indications" then define a term in the documentation for "file progress messages" and create a -q level that squelches those (e.g. -q=2 becomes that and -q=3 becomes silent mode). Either way, the docs are misleading right now. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/874409 Title: apt-get -q flag fails to squelch status -qq hides everything To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/874409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 874409] Re: apt-get -q flag fails to squelch status -qq hides everything
Hmm, that was overly verbose (not to mention, typo-ridden). Here's the short version: there's currently no way to squelch the output to a non- verbose, "did it work or not and why?" However, the documentation, as it reads now seems to imply that such a thing is possible. The documentation should either reflect the reality, or the program should be fixed such that the documentation is correct. IMHO, the latter makes more sense, but I'm not the dev, here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/874409 Title: apt-get -q flag fails to squelch status -qq hides everything To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/874409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 874409] Re: apt-get -q flag fails to squelch status -qq hides everything
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/874409 Title: apt-get -q flag fails to squelch status -qq hides everything To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/874409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 874409] [NEW] apt-get -q flag fails to squelch status -qq hides everything
Public bug reported: According to the docs, apt-get install -q foo should install the package foo, while suppressing progress messages. It does not. Quiet level 2 (-qq or -q=2) will suppress those messages, but also suppresses errors/summary. There is no middle ground. Example: $ sudo apt-get install -q=1 mysql-server Reading package lists... Building dependency tree... Reading state information... mysql-server is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ sudo apt-get install -q=2 mysql-server $ The second example is probably correct output, but the first should suppress "Reading package lists..." type output as they are, as defined in the man page, "progress indicators". Certainly -q should output "mysql-server is already the newest version" which amounts to an error message. It's arguable if the summary "0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded" should be included or not. Either way, the docs are pretty clear that the progress messages don't belong there at all. Another approach would be to add a -q=3 which does what -q=2 does now, and make -q=2 suppress the progress indicators, but then what exactly is -q=1 doing? There must be some output that it does suppress, but I'm not able to tell what it is. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: apt 0.8.13.2ubuntu4.2 ProcVersionSignature: Ubuntu 2.6.38-11.50-generic 2.6.38.8 Uname: Linux 2.6.38-11-generic x86_64 Architecture: amd64 Date: Fri Oct 14 12:13:20 2011 InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1) ProcEnviron: LANGUAGE=en_US:en PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug natty -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/874409 Title: apt-get -q flag fails to squelch status -qq hides everything To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/874409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 506069] Re: X server crashes with "Saw signal 11. Server aborting"
Also seeing this. My setup: I'm loading dbe, extmod, "type 1", freetype and glx. Ximerama 0 is set. Monitors are "DELL 2007FP" H30.0 - 83.0 V56.0 - 76.0 with DPMS Loading the "nvidia" driver with board name "Quadro NVS 285" And here's the screen section: Section "Screen" Identifier "Screen0" Device "Device0" Monitor"Monitor0" DefaultDepth24 Option "TwinView" "1" Option "TwinViewXineramaInfoOrder" "CRT-0" Option "metamodes" "CRT-0: nvidia-auto-select +0+0, CRT-1: nvidia-auto-select +1600+0" SubSection "Display" Depth 24 EndSubSection EndSection Crashes about every other day. Similar backtrace to original report: Backtrace: 0: /usr/bin/X(xorg_backtrace+0x26) [0x4f00c6] 1: /usr/bin/X(xf86SigHandler+0x41) [0x4852c1] 2: /lib/libc.so.6 [0x7f1dfeb05530] 3: /usr/lib/xorg/modules/drivers//nvidia_drv.so(_nv001646X+0x26) [0x7f1dfbd4c856] ... 18: /usr/bin/X [0x433509] Saw signal 11. Server aborting. Installed versions: nvidia-glx-185 185.18.36-0ubuntu9 nvidia-185-kernel-source 185.18.36-0ubuntu9 nvidia-185-libvdpau 185.18.36-0ubuntu9 nvidia-settings 180.25-0ubuntu1 nvidia-common0.2.15.1 xorg 1:7.4+3ubuntu10 xserver-xorg 1:7.4+3ubuntu10 xserver-xorg-core 2:1.6.4-2ubuntu4.1 My installation is fairly vanilla. I don't have any extra repos other than the Google Chrome one. I have a large background spread across both displays and I use the desktop effects settings in the Gnome window manager to enable transparent windows based on stack depth. -- X server crashes with "Saw signal 11. Server aborting" https://bugs.launchpad.net/bugs/506069 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 203217] Re: fast-user-switch heavy cpu usage
Your chmod workaround has simply disabled NIS and automounting, removing all network user and filesystem access from your system. That will certainly solve the problem, but for most people who have this problem, that's throwing out the baby with the bath-water. There are also more standard ways to turn off services. After having lived with this for a while, I think the core problem is not the user list itself, but the fact that the user-switcher wants to look at everyone's home directory. If there are 10,000 users (not as uncommon as you'd think), this means 10,000 network directory lookups (possibly more if it's looking at subdirs as well, I'm not 100% certain what it's fetching other than a potential icon to use for the login session). I discovered this when I went to my automounted /home directory and found all of the users pre-mounted, which should only happen if I'm actually reading their directories. Perhaps the right thing to do here is to simply add in some delays. It doesn't have to search all of the user homedirs at once, does it? Would pausing for 500ms between lookups hurt anything? What's more, is it even useful to be looking up fast-user-switch info when there are thousands of users? -- fast-user-switch heavy cpu usage https://bugs.launchpad.net/bugs/203217 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 15051] Re: grep -P is not supported
I keep re-discovering this fundamental incompatibility between Ubunutu and other Linux distributions. I'd like to just clear up some items that are repeated several times by developers who have replied to this bug: "Perl" is not involved here. PCRE is a broadly used RE library, and only happens to have started as an attempt to bring modern Perl RE features to other languages. Also, while many tools exist which would allow users to search for PCRE- style patterns in text files, that does not address the problem, here: Ubuntu provides a command called "grep", but it fails to provide one of the most frequently used parameters to that command on other Linux platforms. This presents a fundamental incompatibility between Ubuntu and other Linux platforms. The reason which was presented was one of decreasing the bloat in boot- time commands, but that doesn't hold any water; on the same machine, I have Fedora 9 and Ubuntu 8.04 installed. The Ubuntu /bin/grep is 99K. The fedora binary is 84K: $ ls -lh /bin/grep -rwxr-xr-x 1 root root 84K 2008-02-20 01:33 /bin/grep $ ldd /bin/grep linux-gate.so.1 => (0x0011) libpcre.so.0 => /lib/libpcre.so.0 (0x009a8000) libc.so.6 => /lib/libc.so.6 (0x0083d000) /lib/ld-linux.so.2 (0x0081d000) $ ls -lh /bin/grep -rwxr-xr-x 1 root root 99K 2007-10-23 16:58 /bin/grep $ ldd /bin/grep linux-gate.so.1 => (0xb7f21000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc4000) /lib/ld-linux.so.2 (0xb7f22000) Now, granted 1) this small difference is likely due to the version of grep under F9 being older than that under U8.04 and 2) libpcre is 165K, but that's less than 1/10th the size of the libraries we're already linking grep against, so again... what's the objection? Another suggestion was having a /usr/bin/grep which supported the standard options, while /bin/grep could be a cut-down version for boot only. This was shot down because it would change behavior based on the ordering of PATH... which isn't quite accurate. What it would do is fail to meet the default expectation that the -P option would work when /bin was first in your path. If /usr/bin were first, then obviously all of the same commands that worked from /bin would continue to work. Picture, if you will, that this were the case. The confusion caused is exactly the same confusion that systems administrators and developers suffer when they attempt to use the same program from the same author in their shell scripts and Makefile on two distributions of the same operating system... If you feel that that situation is untenable, then you really have to feel that the current situation is as well, unless you're simply taking the provincial view that users should not expect core commands to behave the same between Linux distributions. To circle back around to the question at hand: what breaks if libpcre is placed in /lib? Do we cross or even approach some critical threshold, or are we just resisting this change on the basis of a phantom concern? -- grep -P is not supported https://bugs.launchpad.net/bugs/15051 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 203217] Re: fast-user-switch heavy cpu usage
I'm in an NIS environment with over 8000 users, and am seeing exactly the same problem. Because this manifests as a blank desktop with no panels, it really is not only crippling to users, but nearly impossible for the uninitiated to diagnose. The large amount of CPU usage is secondary, really, the first thing that needs to be fixed is the fact that this blocks the user's desktop initialization. Does it need to? -- fast-user-switch heavy cpu usage https://bugs.launchpad.net/bugs/203217 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
