On Linux.conf.au and Presentation logistics

Jan 06 2014

How to diff LibreOffice Impress presentations in git

These days I keep track of presentation material using git (like many things). One handy trick is you can `git diff` an ODP file and have the text changes show like any other code.

The following procedure will enable this for Debian, YMMV.

  1. sudo apt-get install odt2txt
  2. Edit the file .gitattributes in the repository containing the ODP files. Note that this file is interpreted at each level in the directory structure
  3. Add the following line to the file:
    *.odt diff=odt
  4. You should probably commit .gitattributes as well.

I haven’t yet worked out a way to make this global using ‘git config’ which is a little annoying.

Another quick tip,  to redock the ‘slides’ pane if you manage to set it “loose”, hold CTRL and double click the word ‘slides’ at the top _inside_ the pane window.

And lastly, if anyone can tell me how to get Impress Presenter Mode to actually work with xrandr without obscuring the actual presentation that would be awesome…

Managing to avoid making last minute tweaks to a presentation is another problem not solvable with code ;-) The problem is I always think of improvements each time I re-read my talk, and also once the conference has started I always think of good techniques to try after watching the other speakers…

 

(One miniconf talk down, one to go!)

No responses yet

Quick Tip – AspireOne xrandr

Nov 26 2013

Remember this to get projector:

xrandr  --output VGA1 -s 1440x900 --right-of LVDS1 --auto

No responses yet

Quick Tip – copying colons over ssh and rsync

Nov 19 2013

If you happen to want to copy a file in the current directory with a colon in the name:

this will fail. Possibly after quite a timeout, with a completely unrelated error (unresolved domain name some-file maybe?)

This is because ssh uses colons to separate the user@host part from the filename part.

The fix when the source is on the local computer is to ensure the path starts with a dot:

Incidentally this is related to that old newby fail, forgetting the trailing colon when coping to a destination home directory:

results in a file in the current directory called ‘user@host’. Oops!

No responses yet

Some funky stuff with git – working with tags

Sep 24 2013

Tags form an important part of any version control system. One of the most common use cases is to mark a revision that corresponds to a released software version; this allows reconciliation of bug reports to the correct code, for example.

There are a few tag related operations that are not immediately obvious in git however.

Listing all commits between two tags.

This is simple enough:

Listing all tags between two revisions.

The following command will list all tags from and including ref OLDEST_TAG_OR_BRANCH, along with the abbreviated commit SHA and brief log.  Omit the caret (^) to exclude the starting point from the list.  HEAD means go until the most recent commit in this line, append a caret to exclude it if it is tagged, or replace HEAD with another tag or branchpoint.

git log, and its cousin git rev-list have quite a lot of formatting and selection options, so checkout the man pages (i.e. man git-log and man git-rev-list ; note, individual git subcommand man pages are accessed by prepending ‘git-’ to the subommand.)

Preserving tags during a filter-branch operation.

The command git filter-branch is a powerful tool that can be used to do things such as change the email address of a user of every commit they made, remove specific words from a commit message, fix common spelling mistakes, rearrange the file tree, etc.  It should not be use ad-hoc as it does effectively rewrite the history, invalidating  working copies so should be use with care.  It is often used when migrating from another system into git, or migrating servers, etc.

One trap with filter-branch is that it is easy to lose tags when using the command.  Filter-branch actually makes a new branch, leaving the original untouched in the repository as a kind of backup, called ‘refs/original/refs/heads/YOUR_BRANCH.  Tags remain attached to this _original_ branch, and are not copied to the new branch unless the –tag-filter is employed concurrently with whichever filter is being used.  Then when you use or clone the replacement YOUR_BRANCH, the tags are “gone”!  This is easily fixed:

(a) Edit every commit message in current branch, removing the word “frooble” and replacing it with “foo”.  This happens to “forget” tags on the way

(b) Edit every commit message in current branch, removing the word “frooble” and replacing it with “foo”, this time making sure the tags move to the branch.

Pushing your tags to your remote.

Remember the –tags flag, so that your tags go up to github, etc:

Removing tags on remote.

No responses yet

Something new: dcfldd – a more advanced dd for data transfer

Aug 30 2013

Today I discovered dcfldd, and it was right there in Debian already: apt-get install dcfldd.

This was while building up a new Raspberry Pi image for a project I have in mind.

Specifically, dcfldd provides a progress meter, unlike the ubiquitous dd command. It also appears to be aimed at forensics and advanced data recovery, featuring on the go hashing of data as well.

You can use dcfldd to write an image onto an sdcard in exactly the same way as dd:

dcfldd bs=4096 if=2013-07-26-wheezy-raspbian.img of=/dev/sdl

Sample Progress Output:

141568 blocks (553Mb) written.

It looks like you can get a Windows binary as well.

No responses yet

« Newer posts Older posts »