Bug#754351: Colormake not working on cross-compilers (patch included)
On Thursday 10 July 2014 19:04:39 Ludovic Rousseau wrote: > It looks like the problem is already fixed upstream at > https://github.com/pagekite/Colormake Can you check that upstream version > of colormake works as expected for you? Appears to be working fine. Thanks. -- Dr Andy Parkins andypark...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754351: Colormake not working on cross-compilers (patch included)
Package: colormake
Version: 0.9-1
I was using colormake and noticed that my g++ lines weren't getting coloured
when the compiler was anything other than plain "g++". I'm using a few cross
compilers, but you can test this with the mingw compiler.
Here's an example line:
i686-w64-mingw32-g++ -Wall -O2 -g -mconsole -c main.cc
I believe the problem is in this bit of the gcc regex...
(([[:ascii:]]+-)?g?cc|(g|c)\+\+).*)$
This matches one or more ascii's followed by dash then "cc" or "gcc", but not
"g++". The "|" is within the overall brackets so only allows "ascii-gcc" OR
"g++", so non-crosscompiler "g++" lines were correctly matched. I believe the
fix is the addition of brackets so that gcc|cc|g++|c++ are all an atom apart
from the [ascii] prefix.
(([[:ascii:]]+-)?(g?cc|(g|c)\+\+)).*)$
Now "([[:ascii:]]+-)?" is one optional prefix atom and (g?cc|(g|c)\+\+)) is
the required suffix atom, and can be any of "gcc", "cc", "g++", or "c++".
I've attached a patch that makes this change, but it's trivial enough that it
could be done quicker by hand.
--- /usr/share/colormake/colormake.pl.bak 2014-07-09 13:39:56.0 +0100
+++ /usr/share/colormake/colormake.pl 2014-07-09 13:41:33.0 +0100
@@ -88,7 +88,7 @@
{
$in = 'make';
}
- elsif ($thisline =~ s/^(\s*(libtool:\s*)?((compile|link):\s*)?(([[:ascii:]]+-)?g?cc|(g|c)\+\+).*)$/$col_gcc$1$col_norm/)
+ elsif ($thisline =~ s/^(\s*(libtool:\s*)?((compile|link):\s*)?(([[:ascii:]]+-)?(g?cc|(g|c)\+\+)).*)$/$col_gcc$1$col_norm/)
{
$in = 'gcc';
}
Bug#443090: Fix
Hello, I've just experienced exactly the same problem, but with a bit of playing I've got the pad working again. I had two mice configured in my xorg.conf, one for /dev/input/mice and one for the touch pad. I had "CorePointer" set for /dev/input/mice. When I removed it and put it in the touchpad section, the touchpad sprang back into life. --- Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "Device""/dev/input/mice" Option "Protocol" "ExplorerPS/2" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "CorePointer" Option "Protocol" "auto-dev" Option "HorizScrollDelta" "0" Option "SHMConfig" "true" EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" InputDevice "Synaptics Touchpad" EndSection --- Hope that helps. Andy -- Dr Andy Parkins, M Eng (hons), MIET [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428413: [PATCH] post-receive-email hook: handle order of arguments consistently
On Thursday 2007 June 14, Gerrit Pape wrote: > The post-receive-email hook usually gets its arguments through stdin, but > also supports them to be specified at the command line. The order of the > arguments should consistently follow the documentation no matter how they > are passed to the script. That wasn't done casually. It was done so that the same script would work as an update hook as well. I have no objection to the change, as the update hook was not the right place for generating emails. However, it let me use that same update hook on a system that did not have a git with support for the post-receive hook. Andy -- Dr Andy Parkins, M Eng (hons), MIET [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359328: Fixed in mesa upstream
I found this bug report https://bugs.freedesktop.org/show_bug.cgi?id=5792 Which says "As it turns out this problem is caused by the snapshot builds using outdated Xorg 6.9 sources that are incompatible with the current i915 driver from Mesa. i915 snapshots 20060123 and older should still be OK." So I guess the problem will go away with the next update of mesa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335522: openoffice.org: right mouse button click doesn't work
I have found a work around for this problem. I use KDE as my desktop and have the mouse set to "Focus Strictly Under Mouse"; changing this setting (in Desktop->Window Behaviour->Focus) to any of: Focus Under Mouse Focus Follows Mouse Click To Focus Makes this bug go away. I've found "Focus Under Mouse" to be near enough to "Focus Strictly Under Mouse", so have switched. OpenOffice 2 now shows the right click menu perfectly every time. -- Dr Andy Parkins, M Eng (hons), AMIEE [EMAIL PROTECTED] pgpnl8glD6m1K.pgp Description: PGP signature
Bug#335522: openoffice.org: right mouse button click doesn't work
I'm having the same problem. On three separate installations (admittedly those are all debian/unstable - so perhaps that doesn't prove a lot :-)) I have noticed though, that if the mouse is moving North-West at while you are clicking the menu appears successfully. Could it be that the menu is appearing outside the "menu stays on screen" zone for the pointer and so instantly disappears? Andy -- Dr Andy Parkins, M Eng (hons), AMIEE [EMAIL PROTECTED] pgpqlZf6oMGGT.pgp Description: PGP signature
