Solve AutoMySQLBackup warning mysql.event

Fix for: -- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.

edit /usr/sbin/automysqlbackup (wherever your /etc/cron.daily/automysqlbackup points)
find the OPT="--quote-names" line (about line 354)

Change it to
OPT="--quote-names --events --ignore-table=mysql.event"

OR, (Based upon additional reading of responses):
one of:
OPT="--quote-names --events"

OPT="--quote-names --ignore-table=mysql.event"

The original line suppresses the warning and ignores the table (redundant).
If you wish to have the table in your backup, don't ignore the table, just use --events
If you don't care about the table, ignoring the table will also suppress the event message.

What's optimal? Depends on if you use events and require them to be restored.
http://dev.mysql.com/doc/refman/5.1/en/events-table.html



Reference: http://bugs.mysql.com/bug.php?id=68376

Keep your vim plugins up to date

Scenario:
You go and download a plugin from a website but the website says, "Check GitHub for the most uptodate version."
So you get the tarball or the file you need and all is good. If you're okay with this, stop reading. You don't need to know the rest.

Method 1:
cd ~/.vim
mkdir gits
cd gits
git clone https://github.com/user/pluginname.git
ln -s ~/.vim/gits/pluginname/plugin/something.vim ~/.vim/plugin/something.vim
ln -s ~/.vim/gits/pluginname/doc/something.txt ~/.vim/doc/something.txt
ln -s ~/.vim/gits/pluginname/autoload/something.vim ~/.vim/autoload/something.vim
(if it exists -- editorconfig, for example)
Check also for plugin/python folders for your plugins.

Yes, I realize this is a bit more painful than just extract/install, but only slightly.
Now, if you want the latest update from the plugin, you can
cd ~/.vim/gits/pluginname/
git pull

Method 2:

cd ~/.vim
git init
mkdir gits

git submodule add https://github.com/user/pluginname.git gits/pluginname

now do the linking.

This second method allows you to version your changes across the entire .vim folder.

You also can checkout specific branches of the plugin, etc.

Git make "clean" pull request.

Scenario: You've worked your tail off and *know* you're done with .. whatever you're working on, and can't be bothered to fixup/squash/commits properly to hide your work method to send upstream.

you have the most recent git fetch from upstream and you're ready to do a pull request.

git checkout upstream/master
(you get a warning that you're in headless mode. In this case, great, let's do what it says:)

git checkout -b mybranchforthispullrequest

Now you're basically looking at plain upstream/master.

you can either
git merge mylocalworkingbranch (but this keeps the commit history)

or, if you're *certain* you only want to add/replace files (hopefully, only add)
git checkout mylocalworkingbranch myfileiwanttoadd.ext

git add myfileiwanttoadd.ext

git commit -m "Added myfileiwanttoadd.ext"

and just send the branch to your origin or upstream
git push origin mybranchforthispullrequest

Optionally, go to github and do a pull request from mybranchforthispullrequest.

automysqlbackup error fix

You get this:
mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user 'debian-sys-maint'@'localhost' for table 'cond_instances' when using LOCK TABLES

to fix it:
edit /etc/default/automysqlbackup
change the DNAMES line to this:

DBNAMES=`mysql --defaults-file=/etc/mysql/debian.cnf --execute="SHOW DATABASES" | awk '{print $1}' | grep -v ^Database$ | grep -v ^mysql$ | grep -v ^performance_schema$ | tr \\\r\\\n ,\ `

or, to be succinct: add

 | grep -v ^performance_schema$ 

into the list. If you're doing any different method of DBNAMES, just make sure to exclude performance_schema.

Why is this happening?

automysqlbackup's default configuration attempts to lock tables before dumping. This error isn't specifically automysqlbackup's problem to fix, as much as it's a problem (or not) that performance_schema.cond_instances can't be locked [by debian-sys-maint] at the time of mysqldump, and mysqldump is what's throwing the error.

Is it a problem of backing up or not backing up performance_schema?

I can't answer that for your situation, though if you understand what the table does and how to recreate it you can be better informed about whether the backup is necessary to you. (hint: probably not unless corporately you need to keep all diagnostic logs on everything.) Also, this is not related to the other databases which actually hold your data and which you do want to back up.

 What does grep -v do?

It says, "don't include this in the list". Note, while you're here, that this also includes the "mysql" table. If you need to keep your users and permissions for disaster recovery reasons, you may wish to consider not excluding that table.

What is "Database"? Why is that grep -v? I don't have a database called Database.

Database is the column title of the result of "SHOW DATABASES" SQL query.

Ubuntu Waiting for network message on bootup

Simple fix for this:
edit /etc/network/interfaces
make sure "auto" only points to network devices that actually will be and need to be on your network (for services) at boot time.

For instance, wlan0 may *not* be online before your OS loads.

Or, you might have other "auto" devices that obtain an ip address via DHCP. The failsafe allows sufficient time to get a DHCP address. You may decide whether you want to disable the failsafe or disable the auto, but note that some services depend on at least eth0 being "alive" before they start (or your ethn configured device).

Since you're there, it's a good idea to check for legacy network devices you may have configured in the past and make sure they're not "auto".

(If you're using DHCP and this configuration does not work for you, it's an issue with DHCP.)

git branch before pull

Things are going well on your version of production/master and you'd like to pull the latest iteration. Oh, sure, you could tar your setup before doing that in case it breaks, but maybe you're stuck for time and too lazy. That's okay. Really it is. just
git branch before-pull-todaysdate
git pull

PANIC! bad stuff, things crashing, etc... maybe that pull isn't nice.
git checkout before-pull-todaysdate

whew... sanity restored. ... OK, it's off hours and you really want to get back to the latest iteration. Managers aren't on your back and you can fix this.
git checkout master

errors, etc. but at least you're at the latest iteration.

BETTER: don't pull. Just git fetch, then git merge when you're ready.

git branch change oops wrong branch

Specific case:

You're working on a feature but forgot to change branches. This feature is going to corrupt master, it seems, but you haven't committed yet.

alternative to stash,
git branch newbranchname
git checkout newbranchname
git add .
git commit -m "I needed a branch for this before killing master"

if you git checkout master, all these new previously uncommitted changes aren't there (whew) but git checkout newbranchname has the stuff you've been working on.

when you're ready to put them back, just merge back to master.